Replies: 12 comments 28 replies
-
|
Since you have the AVR EB chip and serialupdi programmer, maybe you want to help to check if you can reproduce the same issues as @askn37. Thanks. Edit: maybe not a good idea for you to carry out the tests, the issues raised seem to belong to more advanced topic and may destroy the chip. |
Beta Was this translation helpful? Give feedback.
-
Avrdude does not read the ASI status register after erase, (at least not when programming an avrEA or AVREB device). It reads the NVM status register. The problem is avrdude is reading the NVM status register using an invalid address (0x1002). With the EB devices, the NVM Status register has moved to 0x1006 not 0x1002 as in all others previously. here is a log from avrdude when programming an AVR16EB32: You can see in the log "LD from 0x001002" is actually reading the NVM Status, waiting for a zero response (all flags cleared). This shouldn't work!!. It should be "LD from 0x001006". I suspect the reason why it works because by the time avrdude executes another command, the BUSY flags have been cleared. With all avr, attiny and atmega's previous to the Ex, the NVM Status register location is 0x1002. |
Beta Was this translation helpful? Give feedback.
-
It is not taken down. It is still there. But as you mentioned in the post, it is better to start another discussion as it is a different issue. |
Beta Was this translation helpful? Give feedback.
-
In order to disable UPDI the UPDI Protection Activate Key PDICFG (bits 15: 4) must be written as I accidentally wrote the UPDI Protection Activate Key PDICFG (bits 15: 4) to a non specific value and left the UNPROT bits as normal. The lock bits were not programmed, however I cannot reprogram it, erase it or otherwise. The response from the chip is that the RSTSYS is active and won't release. So even though the UPDI Protection Level is 11, the UPDI is still disabled or in a state where it is not accepting commands. I ordered some more avr16EB32 and until I receive the order, I won't be able to do any testing on the EB's. It may be a good idea to leave this fuse inaccessible to avrdude. |
Beta Was this translation helpful? Give feedback.
-
Great catch @avrfreak! Looks like the constants in Lines 109 to 118 in 03d786e need to be replaced with a computation what the corresponding address should be. One way of doing so is the register file table that AVRDUDE knows about for each part. Here some prototype code for the terminal Lines 1632 to 1637 in 03d786e Using that one can find the address of "nvmctrl.status" in that register file structure. The structures are in avrintel.[ch], eg,
{"nvmctrl.ctrla", 0x1000, 1, -1, 0x00, "control register A"},
{"nvmctrl.ctrlb", 0x1001, 1, -1, 0x30, "control register B"},
{"nvmctrl.ctrlc", 0x1002, 1, -1, 0x00, "control register C"},
{"nvmctrl.intctrl", 0x1004, 1, -1, 0x00, "interrupt control register"},
{"nvmctrl.intflags", 0x1005, 1, -1, 0x00, "interrupt flags register"},
{"nvmctrl.status", 0x1006, 1, -1, 0x00, "status register"},
{"nvmctrl.data", 0x1008, 4, -1, 0x00000000, "data register (32 bits)"},
{"nvmctrl.addr", 0x100c, 4, -1, -1, "address register (32 bits)"},
};
// AVR64DA32 AVR128DA32
const Register_file_t rgftab_avr64da32[448] = { // I/O memory [0, 4159]
{"vporta.dir", 0x0000, 1, -1, 0x00, "data direction register"},
{"vporta.out", 0x0001, 1, -1, 0x00, "I/O port output register"},
{"vporta.in", 0x0002, 1, -1, 0x00, "I/O port input register"},@askn37 Are you up for creating a PR for this problem? We might want to merge a solution for this for v7.3. Also, Dawid @dbuchwald, might want to comment or suggest a better solution or even a PR for this? |
Beta Was this translation helpful? Give feedback.
-
|
Differences between versions of NVMCTRL are summarized here.
It has been known for some time that serialupdi does not correctly read the new format of NVMCTRL_STATUS (yet), but the communication speed is slow enough that no fatal problem has surfaced. The chip erase issue I discovered can be seen in the following logs from serialupdi: This is the UPDI (OCD) part, not NVMCTRL. Although Serialupdi's UPDI operations fully follow known publicly available conventions and are not suspicious, we can see that the chip is not responding as expected. Edit: This chip is now unable to restore LOCK.KEY, but the STK500v1 bootloader (boot_ex) is still working, so you can still observe the inside of the chip with APPCODE privileges. You can confirm that even though "brown fox" is written in BOOTROW, it cannot be read correctly. |
Beta Was this translation helpful? Give feedback.
-
|
@stefanrueger thank you for letting me know about this issue. I spent some time this morning looking into it, and I would suggest different approach: I need to update the |
Beta Was this translation helpful? Give feedback.
-
|
Wonderful news, @dbuchwald! Yes, please, a PR would be wonderful. |
Beta Was this translation helpful? Give feedback.
-
|
Short update, not that it matters, but I was wondering how comes I made such a silly mistake (hardcoding NVM STATUS register to 0x02 offset, while it's not actually shared between devices). It's truly amazing how long this went on unnoticed! |
Beta Was this translation helpful? Give feedback.
-
I suspect that at the time Microchip had not realised their register layout might change in future, so they hard-coded it in |
Beta Was this translation helpful? Give feedback.
-
|
Hey, short update: I spent more time today investigating possible fix, and while sorting out the register offsets is relatively straightforward, there is different problem to handle. Turns out that when Microchip introduced new NVM controller versions, they have also changed their In previous if status & (1 << constants.UPDI_NVM_STATUS_WRITE_ERROR):
self.logger.error("NVM error")
return False
Now this is what they are doing: if status & self.STATUS_WRITE_ERROR_bm:
self.logger.error("NVM error (%d)", status >> self.STATUS_WRITE_ERROR_bp)
raise PymcuprogSerialUpdiNvmError(msg="NVM error", code=(status >> self.STATUS_WRITE_ERROR_bp))Value of That probably explain many smaller strange things that were happening in the past, but it also means that I have to redo quite a lot of my implementation, and what's even worse, test it again. Bottom line: it will be bigger, longer and more risky implementation. Sorry. |
Beta Was this translation helpful? Give feedback.
-
|
Brilliant, @dbuchwald thanks for keeping on top of this. I tend to think this is important enough to put into v7.3, so vvv happy to wait until you are happy with it. |
Beta Was this translation helpful? Give feedback.
-
|
Still testing with another AVR16EB32 chip. At this time, we have confirmed that UPDI_ASI + CHIPERASE works correctly if LOCK.KEY and FUSE.PDICFG are in their default states. I also suspected the influence of the FUSE_SYSCFG0.BROWSAVE bit, but it doesn't seem to be related. (The log below also includes loopback echoes of UPDI single-line communication, so the transmitted characters are displayed twice.) On the other hand, it has been newly discovered that when writing the NVMPROG key with ASI_SYS_STATUS.PROGSTART set, there is no UPDI response and ASI_KEY_STATUS cannot be read. I have never encountered this phenomenon in the past. This indicates a potential problem, as it is a common procedure to write the NVMERASE key and its NVMPROG key at the same time to eliminate unexpected effects when the CRCSCAN feature is enabled. |
Beta Was this translation helpful? Give feedback.
-
|
@askn37 @stefanrueger What has been done so far:
Still to be done:
I have just found out that I can finally buy PDIP version of EA chip, expecting it to arrive early next week, so I will be able to perform a bit more tests, but I would really appreciate your support with this. Since I haven't filed official PR yet, you need to fetch the code from my own repo, which is fork of this repository. You will find my changes in branch https://github.com/dbuchwald/avrdude/tree/issue_1609 Let me know if you run into any issues with this version. In the meantime I will carry on with my (limited) testing and keep implementing V4 and proper V5 support. |
Beta Was this translation helpful? Give feedback.
-
Of course, we would like to cooperate with each other. Maintaining the quality of code used in production requires many reviews. The created fragments are codes that represent "concepts" for visualizing or avoiding phenomena. Don't simply accept it. Substantive processing such as timeout avoidance is not included. Don't you think it's easier to understand by reading a code sample than explaining the content in a language you're not good at? |
Beta Was this translation helpful? Give feedback.
-
|
FYI, it looks be able to get my hands on some AVR-DU chips next week or the week after that. |
Beta Was this translation helpful? Give feedback.
-
|
Good news. By the way, the firmware for the debugger products was also updated this week. It only says "New device support". |
Beta Was this translation helpful? Give feedback.
-
|
@askn37 I received AVR16EB28 chip in the mail today, so I have now both V3 and V5 chips to test these V3+ specific scenarios. I have also filed the three issues:
Otherwise, can we continue discussion about these specific issues in their dedicated threads? @stefanrueger, @MCUdude - I wasn't able to tag these issues as bugs, could you do that for me? |
Beta Was this translation helpful? Give feedback.
-
|
Some of the detected suspects were correctly flagged, segmented, and tagged as problematic. To make this page more readable, I think you can fold or hide some of the comments. |
Beta Was this translation helpful? Give feedback.
-
|
As an aside, AVR_EB's BOOTROW is not very convenient. At best, you can come up with a preset save for your waveform generator. However, AVR_DU's BOOTROW is expanded to 256 bytes. This gives me another possibility. AVR_DU is equipped with one USB device controller. Looking at the header files, it looks almost identical to the high-performance implementations of the XMEGA generation. The difference is that the "Low-speed" support appears to have been removed. Since BOOTROW is large enough to store USB device descriptors, it seems possible to reduce the size of the DFU bootloader from 1.0KiB to 1.5KiB. In that case, the firmware will be split into two files. Programmers who cannot write to BOOTROW may not be able to update the DFU bootloader. If I had to guess, Microchip Lab's current work is the development of his DFU bootloader. Firmware is then written to the AVR_DU and shipped. New USB vendor IDs and product IDs are also assigned for each product type. We don't know if it will be traditional firmware or based on new ideas. My advice to myself is that when you get a new chip, remember to back up his BOOTROW in addition to the FLASH backup. |
Beta Was this translation helpful? Give feedback.
-
|
@dbuchwald Please continue with your own plan at your own pace. I am convinced your careful analysis, programming and testing is good for the AVRDUDE project. Your serialupdi implementation has been exemplary (and the problems we see now can be tracked to Microchip!) |
Beta Was this translation helpful? Give feedback.
-
|
PR #1627 has been merged and I will close this one. |
Beta Was this translation helpful? Give feedback.
-
Now that I've got a bare AVR16EB32 chip, I've been doing some physical research and found an interesting issue that's also related to AVRDUDE, so I'd like to share it with you. If you are just getting started with the AVR EB Series, please read the overview below first.
DataSheet PDF - https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/DataSheets/AVR16EB14_20_28_32-Prelim-DataSheet-DS40002522.pdf
Eratta PDF - https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/Errata/AVR16EB14-20-28-32-SilConErrataClarif-DS80001107.pdf
Sample Chip Summary
Major issues not yet (probably) in the errata
The chip I am currently trying cannot erase the chip from UPDI ASI. The erase key is accepted correctly, but after reset ASI_STATUS returns 0xD0 or 0xD1 and the chip erase fails.
This phenomenon has been confirmed using SerialUPDI. Normal chip erase is done with NVMCTRL's CHER command so it's not a problem, but if it's a locked chip he tries to erase with UPDI ASI and it fails.
Of course, this could be a problem specific to the chip you got, but be very careful when discarding your LOCK.KEY.
CRCSCAN does not work properly with some flash areas.
This has already been added to Eratta and is the same issue that exists in AVR EA. This is a design error due to FUSE_CODESIZE/BOOTSIZE being incorrectly interpreted as a multiple of 512 bytes. This issue has been fixed in the latest revision of AVR EA and should be fixed in the next product revision of AVR EB.
About the BOOTROW area
As expected, UPDI and NVMCTRL treat this as flash memory. So "avrdude_main -c serialupdi" is fully readable and writable. Reading and writing using JTAG2UPDI (clone) is also possible. (However, chip erasure is only possible using the ASI method, so modification is required.)
On the other hand, BOOTROW is a secret area exclusively for BOOTCODE, so it cannot be read or written from APPCODE. Always read as zero. Note that if your bootloader does not come with a read/write snippet, it will not be available at all from the APPCODE. ((E)LPM/SPM cannot be used to read/write this area. LD/ST instructions are used.)
About FUSE.PDICFG
If you destroy LOCK.KEY and rewrite FUSE.PDICFG to a specific value, UPDI will be completely disabled. Once that happens, there is no way to recover from the brick.
About High-Voltage control
The absolute rating of the RESET/PF6 pad has been reduced to 8.5V. The recommended value is 7.5V. This is 1V lower than the AVR DD, so if you're clamping the voltage with a Zener diode you'll need to rethink your circuit.
Beta Was this translation helpful? Give feedback.
All reactions