Closed askn37 closed 1 year ago
stefanrueger
commented
1 year ago @dbuchwald Do you want to have a look? I suspect that 24-bit addresses are needed for the 64k device because the effective address after adding the flash offset exceeds 16 bit.
dbuchwald
commented
1 year ago I will take a look, but might not be able to test it though, as I don't have the AVR64EA32 chip at hand. Anyway, will keep you posted!
dbuchwald
commented
1 year ago OK, so this is what I came up with: according to the logs above, NVM link mode is version 3, which is 16-bit address/page oriented write. I checked it again in the original Microchip's pymcuprog implementation, and this is what they do:
And this is what I do:
https://github.com/avrdudes/avrdude/blob/main/src/serialupdi.c#L163
So, as long as the chip itself reports to be NVM link version 3, we should and will use 16-bit addresses.
The only thing I can suggest now is for @askn37 to try to program the original device using pymcuprog software and see if it works. If it fails, then probably there is some bug in interface/documentation provided by Microchip. If it does work, then please, run pymcuprog with the highest verbosity level and post the output here - it will produce almost identical trace (with all the NVM commands listed), and I can use it to trace the issue back to the source.
mcuee
commented
1 year ago Edit: I realized that the issue is about SerialUPDI. I need to see how I can test this. I have not soldered the pin headers. I will see if I can carry out the test using serialupdi next week.
+++++++++++++++++ I tested this before avrdude 7.2 release and it was okay. https://github.com/avrdudes/avrdude/discussions/1257#discussioncomment-6203438
Just tested again with latest git main and it is still okay. I am using Microchip AVR64EA48 Curiosity Nano bought from Mouser SIngapore.
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude
Usage: avrdude [options]
...
...
avrdude version 7.2-20231018 (481a91dd), https://github.com/avrdudes/avrdude
P> .\avrdude -c pkobn_updi -p avr64ea48 -U .\median_Release_1.0.0.hex
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e961e (probably avr64ea48)
avrdude: Note: flash memory has been specified, an erase cycle will be performed.
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: processing -U flash:w:.\median_Release_1.0.0.hex:i
avrdude: reading input file .\median_Release_1.0.0.hex for flash
with 5122 bytes in 1 section within [0, 0x1401]
using 41 pages and 126 pad bytes
avrdude: writing 5122 bytes flash ...
Writing | ################################################## | 100% 2.49 s
avrdude: 5122 bytes of flash written
avrdude: verifying flash memory against .\median_Release_1.0.0.hex
Reading | ################################################## | 100% 1.24 s
avrdude: 5122 bytes of flash verified
avrdude done. Thank you.Full debug log here.
mcuee
commented
1 year ago @askn37
I have changed the label to unconfirmed for now. Please follow the suggestion from @dbuchwald.
I will change the lable back to bug if another user or I can confirm the issue. Thanks.
mcuee
commented
1 year ago @stefanrueger and @dbuchwald
I can not test this right now but I am not sure if you can get some useful info from my debug log using the -c pkobn_updi programmer. Please take a look the debug log. Thanks.
stefanrueger
commented
1 year ago @askn37 Thanks for reporting and for expanding your submission with additional information. Could I ask you to give the complete line, including which -c programmer etc where you get IO memory instead of flash, please. So, we can try to reproduce. You appear to use -U flash:r:avr64ea32/Flash.hex:i as one element.
dbuchwald
commented
1 year ago @mcuee if you have access to Curiosity Nano board with AVR64EA32 (or AVR64EA48) chip, you can connect your SerialUPDI programmer like so:
I know it looks flimsy AF, but it does work, good enough to run some tests.
That being said, I want to clarify something - my implementation of SerialUPDI in AVRDUDE was always meant to be just a port of Python-based Microchip reference implementation. It was never built directly based on chip datasheets, an for a reason. I could have never dreamt of testing my code against statistically significant sample of the actual microcontrollers, so following manufacturer's reference implementation was the only "natural" thing to do. This is why I need comparison between pymcuprog and AVRDUDE, I need to know how the reference implementation handles support for these processors. Sure, I can add new parameter to the programmer to enable 24-bit operation on NVM v3 and offer it as an experimental feature, but I would be hesitant to changing the core implementation based on datasheet of a chip I can't get my hands on in reasonable timeframe.
Bottom line: I really need to know two things:
Please note: English is not my first language, and now rereading the above it sounds like I don't want to handle this issue, but that would be wrong impression. I really do want to help, and I'm happy to experiment with different approaches, but I really need to know that whatever we are trying to do here will not break existing functionality.
mcuee
commented
1 year ago @dbuchwald
Thanks a lot for the tip. I will try to get some compariosons done tomorrow.between pymcuprog and avrdude.
No worry, you have been very helpful to avrdude project.
askn37
commented
1 year ago @mcuee
- How does pymcuprog handle scenarios with "resetting"/"sleeping" chip (as far as I recall, it doesn't), and how to reproduce this behavior (how to put one of the Dx chips I do have in these states),
- How does pymcuprog handle programming of the AVR64EA32 chips.
Please note: English is not my first language, and now rereading the above it sounds like I don't want to handle this issue, but that would be wrong impression. I really do want to help, and I'm happy to experiment with different approaches, but I really need to know that whatever we are trying to do here will not break existing functionality.
Unfortunately, it appears that pymcuprog has not been updated since October 2022. Microchip published his AVR16EAxx and AVR32EAxx repositories in April 2023 and began shipping engineering samples to customers. Therefore, it is unlikely that pymcuprog can expect full compatibility with his NVMCTRL version 3.
In fact, the first release of Microchip's AVR-LIBC library for his AVR32EAxx had an EEPROM control bug that incorrectly used version 0 code for NVMCTRL version 3. I first discovered it and reported it to Microchip. The repository was properly modified and published in July.
I have never tested pymcuprog before. Because debugging Python is not my main job. However, if new issues are discovered, you will need to report them to Microchip again.
(By the way, my native language is Japanese. Conversation with a microchip is quite troublesome.)
mcuee
commented
1 year ago @xedbg
Just wondering if you can help to check here. Thanks.
stefanrueger
commented
1 year ago I'm happy to experiment with different approaches
Thank you, @dbuchwald. This is great. Given the choice between a working implementation and one that's conform to a possibly outdated reference implementation, I'd go for the former in a heartbeat. It would be good if you could continue to look after the UPDI implementation @dbuchwald. Many thanks all round, @mcuee for testing and @askn37 for making us aware of this problem. (@askn37 if you have specific code suggestions to try, please feel free to share).
dbuchwald
commented
1 year ago @mcuee if you get some time to replicate the issue, you can also grab the version I just provided via PR above - it basically replaces 16-bit addressing mode for NVM v3 controllers by 24-bit mode. You can test if it works any better. The main problem I see now is that I don't know if there is any reasonable way to get list of devices using NVM v3 and test them against this implementation. As for Microchip dropping support for pymcuprog/serialupdi, this is unfortunate, but somehow consistent with their way of operation. Let's leave it there.
If it works, then we need to look into this "sleep" mode, and as far as I can tell from the datasheet, it might not be trivial thing to do:
_The UPDI PHY layer runs independently of all sleep modes, and the UPDI is always accessible for a connected debugger independent of the device’s sleep state. If the system enters a sleep mode that turns the system clock off, the UPDI cannot access the system bus and read memories and peripherals. When enabled, the UPDI will request the system clock so that the UPDI always has contact with the rest of the device. Thus, the UPDI PHY layer clock is unaffected by the sleep mode’s settings. By reading the System Domain in Sleep (INSLEEP) bit in the ASI System Status (UPDI.ASI_SYS_STATUS) register, it is possible to monitor if the system domain is in a sleep mode. It is possible to prevent the system clock from stopping when going into a sleep mode by writing to the Request System Clock (CLKREQ) bit in the ASI System Control A (UPDI.ASI_SYSCTRLA) register. If this bit is set, the system’s sleep mode state is emulated, and the UPDI can access the system bus and read the peripheral registers even in the deepest sleep modes.
mcuee
commented
1 year ago I will label this as bug for now based on the reports by @askn37. But I will try to carry out the test to confirm later.
mcuee
commented
1 year ago @dbuchwald
I can confirm there is an issue in git main and your PR #1531 helps, at least for reading. For writing I still encounfer faliures but I do not have a steady hand now to hold the pin headers long enough. I will do that later.
1) git main failed to verify flash contents (I used the on-board programmer to program the flash first and then verify with serialupdi.
PS> .\avrdude_git -c serialupdi -P COM9 -p avr64ea48 -U flash:v:median_Release_1.0.0.hex:i
avrdude_git: AVR device initialized and ready to accept instructions
avrdude_git: device signature = 0x1e961e (probably avr64ea48)
avrdude_git: processing -U flash:v:median_Release_1.0.0.hex:i
avrdude_git: verifying flash memory against median_Release_1.0.0.hex
Reading | ################################################## | 100% 1.19 s
avrdude_git warning: verification mismatch
device 0x00 != input 0x5c at addr 0x0000 (error)
avrdude_git error: verification mismatch
avrdude_git done. Thank you.PR #1531 is good in terms of verification.
PS> .\avrdude_pr1531 -C .\avrdude_pr1531.conf -cserialupdi -PCOM9 -pavr64ea48 -U flash:v:median_Release_1.0.0.hex:i
avrdude_pr1531: AVR device initialized and ready to accept instructions
avrdude_pr1531: device signature = 0x1e961e (probably avr64ea48)
avrdude_pr1531: processing -U flash:v:median_Release_1.0.0.hex:i
avrdude_pr1531: verifying flash memory against median_Release_1.0.0.hex
Reading | ################################################## | 100% 1.19 s
avrdude_pr1531: 5122 bytes of flash verified
avrdude_pr1531 done. Thank you.For writing I still encounfer faliures but I do not have a steady hand now to hold the pin headers long enough. I will do that later.
@dbuchwald
I managed to hold the pin header and PR #1531 is good as well.
PS > .\avrdude_pr1531 -C .\avrdude_pr1531.conf -c serialupdi -P COM9 -p avr64ea48 -U median_Release_1.0.0.hex
avrdude_pr1531: AVR device initialized and ready to accept instructions
avrdude_pr1531: device signature = 0x1e961e (probably avr64ea48)
avrdude_pr1531: Note: flash memory has been specified, an erase cycle will be performed.
To disable this feature, specify the -D option.
avrdude_pr1531: erasing chip
avrdude_pr1531: processing -U flash:w:median_Release_1.0.0.hex:i
avrdude_pr1531: reading input file median_Release_1.0.0.hex for flash
with 5122 bytes in 1 section within [0, 0x1401]
using 41 pages and 126 pad bytes
avrdude_pr1531: writing 5122 bytes flash ...
Writing | ################################################## | 100% 1.91 s
avrdude_pr1531: 5122 bytes of flash written
avrdude_pr1531: verifying flash memory against median_Release_1.0.0.hex
Reading | ################################################## | 100% 0.93 s
avrdude_pr1531: 5122 bytes of flash verified
avrdude_pr1531 done. Thank you.git main will fail.
PS > .\avrdude_git -c serialupdi -P COM9 -p avr64ea48 -U median_Release_1.0.0.hex
avrdude_git: AVR device initialized and ready to accept instructions
avrdude_git: device signature = 0x1e961e (probably avr64ea48)
avrdude_git: Note: flash memory has been specified, an erase cycle will be performed.
To disable this feature, specify the -D option.
avrdude_git: erasing chip
avrdude_git: processing -U flash:w:median_Release_1.0.0.hex:i
avrdude_git: reading input file median_Release_1.0.0.hex for flash
with 5122 bytes in 1 section within [0, 0x1401]
using 41 pages and 126 pad bytes
avrdude_git: writing 5122 bytes flash ...
Writing | ##------------------------------------------------ | 4% 2.16 s
avrdude_git error: commit data command failed
avrdude_git error: wait NVM ready timed out
avrdude_git error: updi_nvm_wait_ready() failed
***failed;
avrdude_git error: wait NVM ready timed out
avrdude_git error: updi_nvm_wait_ready() failed
***failed;
avrdude_git error: wait NVM ready timed out
avrdude_git error: updi_nvm_wait_ready() failed
***failed;
avrdude_git error: wait NVM ready timed out
avrdude_git error: updi_nvm_wait_ready() failed
***failed;
avrdude_git error: wait NVM ready timed out
avrdude_git error: updi_nvm_wait_ready() failed
***failed;
avrdude_git error: wait NVM ready timed out
avrdude_git error: updi_nvm_wait_ready() failed
***failed;
(I hit CTRL-C to exit)BTW, I need to mention that the nice setial2updi adapter (with pogo-pins or pin headers) is courtesy of @SpenceKonde (aka Dr. Azzy).
He is very kind and sent me the following at the end of last year. 1) Nice serialupdi adapter with pogo pins and pin headers 2) AVR64DD32 board 3) AVR32DD14 breakout board 4) ATTiny3227 breakout board
mcuee
commented
1 year ago @askn37
Please give PR #1531 a try. Thanks. My testing shows that it works fine.
askn37
commented
1 year ago I would like to thank you all for your great work.
The attached code is a program that allows you to experience sleep failures (rather than address width issues). This applies to tinyAVR-2 and most of its AVR_DA/DB/DD/EA/EB. It can be constructed with AVR-LIBC.
When I run it, the LED keeps blinking using PA7, but the CPU remains in a STANDBY sleep state with interrupts disabled. Also, F_CPU is 512Hz.
(TCB0, CCL, and EVOUT are used for this LED blinking operation, but tinyAVR-0/1 and megaAVR-0 are not supported because the difference in CCL is troublesome.)
Please upload your code to the device using a method other than the problematic SerialUPDI and test it with SerialUPDI. It is important not to reset the CPU at this point. The CPU startup start time is affected by the SUT setting value of FUSE_SYSCFG1.
To test without going to sleep, run a SerialUPDI with the reset pad LOW, wait a second or two, then release the reset. SerialUPDI should be able to recognize the CPU. A power-on reset is required if the chip's reset pad functionality is disabled in FUSE_SYSCFG0.
Engineering samples of the AVR16EBxx will begin arriving to stakeholders soon. It seems that the application for free distribution has ended. moderAVR_sleep_c.txt
xedbg
commented
1 year ago Just wondering if you can help to check here. Thanks.
Sure, i can take a closer look today. But something does looks off here - the 'default' should use 24-bit UPDI going forward for all parts.
dbuchwald
commented
1 year ago But something does looks off here - the 'default' should use 24-bit UPDI going forward for all parts.
And that was the change I made - chips reporting NVM v3 are now handled with 24-bit addressing. That being said, it would be great to find some sort of list of all the devices using this NVM mode to test it with more than one or two...
mcuee
commented
1 year ago If it works, then we need to look into this "sleep" mode, and as far as I can tell from the datasheet, it might not be trivial thing to do:
_The UPDI PHY layer runs independently of all sleep modes, and the UPDI is always accessible for a connected debugger independent of the device’s sleep state. If the system enters a sleep mode that turns the system clock off, the UPDI cannot access the system bus and read memories and peripherals. When enabled, the UPDI will request the system clock so that the UPDI always has contact with the rest of the device. Thus, the UPDI PHY layer clock is unaffected by the sleep mode’s settings. By reading the System Domain in Sleep (INSLEEP) bit in the ASI System Status (UPDI.ASI_SYS_STATUS) register, it is possible to monitor if the system domain is in a sleep mode. It is possible to prevent the system clock from stopping when going into a sleep mode by writing to the Request System Clock (CLKREQ) bit in the ASI System Control A (UPDI.ASI_SYSCTRLA) register. If this bit is set, the system’s sleep mode state is emulated, and the UPDI can access the system bus and read the peripheral registers even in the deepest sleep modes.
If this is not trivial to do, I think we can just document this as a limitation.
mcuee
commented
1 year ago But something does looks off here - the 'default' should use 24-bit UPDI going forward for all parts.
And that was the change I made - chips reporting NVM v3 are now handled with 24-bit addressing. That being said, it would be great to find some sort of list of all the devices using this NVM mode to test it with more than one or two...
Do you know other AVR families which use NVM v3?
dbuchwald
commented
1 year ago If this is not trivial to do, I think we can just document this as a limitation.
I will try to reproduce the issue using the code provided by @askn37, and if it occurs on a hardware that I do have at hand (Curiosity Nano with AVR128DA), I can see if there is any procedure that would "wake up" the chip. So far I haven't found any suggestion in the datasheet, but I need to look deeper. At the very least I can try to read the status register to check if device is asleep and display some sort of information.
Do you know other AVR families which use NVM v3?
Nope. I actually found my original PR with first implementation of SerialUPDI interface https://github.com/avrdudes/avrdude/pull/772 and found this part of the comment:
NVM mode 3 has not been tested, since I don't have EA-series chips either. I don't even know if they can be obtained
So yeah, testing against another NVM v3 device would be great...
xedbg
commented
1 year ago But something does looks off here - the 'default' should use 24-bit UPDI going forward for all parts.
And that was the change I made - chips reporting NVM v3 are now handled with 24-bit addressing. That being said, it would be great to find some sort of list of all the devices using this NVM mode to test it with more than one or two...
Do you know other AVR families which use NVM v3?
I think its just EA. (DU uses P:4 and EB uses P:5)
askn37
commented
1 year ago @dbuchwald: The easiest way is to get information other than UPDI_SIB after "entering NVM programming mode". It is now guaranteed to be unaffected by the execution state of the target CPU.
@mcuee: The AVR_EA and AVR_EB series are currently known to use NVMCTRL version 3. As proof, look for the "ioavr16eb32.h" file in his PACK, available at Microchip Packs Repository. And check the NVMCTRL_CMD_enum information. Let's also take a look at "#define NVMCTRL_ADDR". This is where the differences between the versions of NVMCTRL become apparent.
mcuee
commented
1 year ago @mcuee: The AVR_EA and AVR_EB series are currently known to use NVMCTRL version 3. As proof, look for the "ioavr16eb32.h" file in his PACK, available at Microchip Packs Repository. And check the NVMCTRL_CMD_enum information. Let's also take a look at "#define NVMCTRL_ADDR". This is where the differences between the versions of NVMCTRL become apparent.
Thanks a lot for the tip. I have just refreshed my atdf repo. The only missing pack seems to be AVR32 DFP.
I am not good at using Bash commands. So I use a crude method. There are only 13 files containing the nvm_ctrl_avr_v3 string and then the number of AVR EA and EB atdf files are also 13.
MINGW64 /c/work/avr/avrdude_test/atdf
$ ls -la *.atdf | wc -l
387
$ cat AVR64EA48.atdf | grep nvm_ctrl_avr_v3
<module id="nvm_ctrl_avr_v3" name="NVMCTRL">
id="nvm_ctrl_avr_v3"
$ cat AVR16EB32.atdf | grep nvm_ctrl_avr_v3
<module id="nvm_ctrl_avr_v3" name="NVMCTRL">
id="nvm_ctrl_avr_v3"
$ cat *.atdf | grep nvm_ctrl_avr_v3
<module id="nvm_ctrl_avr_v3" name="NVMCTRL">
id="nvm_ctrl_avr_v3"
<module id="nvm_ctrl_avr_v3" name="NVMCTRL">
id="nvm_ctrl_avr_v3"
<module id="nvm_ctrl_avr_v3" name="NVMCTRL">
id="nvm_ctrl_avr_v3"
<module id="nvm_ctrl_avr_v3" name="NVMCTRL">
id="nvm_ctrl_avr_v3"
<module id="nvm_ctrl_avr_v3" name="NVMCTRL">
id="nvm_ctrl_avr_v3"
<module id="nvm_ctrl_avr_v3" name="NVMCTRL">
id="nvm_ctrl_avr_v3"
<module id="nvm_ctrl_avr_v3" name="NVMCTRL">
id="nvm_ctrl_avr_v3"
<module id="nvm_ctrl_avr_v3" name="NVMCTRL">
id="nvm_ctrl_avr_v3"
<module id="nvm_ctrl_avr_v3" name="NVMCTRL">
id="nvm_ctrl_avr_v3"
<module id="nvm_ctrl_avr_v3" name="NVMCTRL">
id="nvm_ctrl_avr_v3"
<module id="nvm_ctrl_avr_v3" name="NVMCTRL">
id="nvm_ctrl_avr_v3"
<module id="nvm_ctrl_avr_v3" name="NVMCTRL">
id="nvm_ctrl_avr_v3"
<module id="nvm_ctrl_avr_v3" name="NVMCTRL">
id="nvm_ctrl_avr_v3"
$ ls *EA*.atdf
AVR16EA28.atdf AVR16EA32.atdf AVR16EA48.atdf AVR32EA28.atdf AVR32EA32.atdf
AVR32EA48.atdf AVR64EA28.atdf AVR64EA32.atdf AVR64EA48.atdf
$ ls *EB*.atdf
AVR16EB14.atdf AVR16EB20.atdf AVR16EB28.atdf AVR16EB32.atdf
$ ls *.atdf -laG --time-style=long-iso | awk '{print $4, $5, $6, $7}'
399906 2020-09-18 15:57 AT32UC3A0128.atdf
399907 2020-09-18 15:57 AT32UC3A0256.atdf
399907 2020-09-18 15:57 AT32UC3A0512.atdf
381293 2020-09-18 15:57 AT32UC3A1128.atdf
381293 2020-09-18 15:57 AT32UC3A1256.atdf
381293 2020-09-18 15:57 AT32UC3A1512.atdf
515771 2020-09-18 15:57 AT32UC3A3128.atdf
524960 2020-09-18 15:57 AT32UC3A3128S.atdf
515771 2020-09-18 15:57 AT32UC3A3256.atdf
524960 2020-09-18 15:57 AT32UC3A3256S.atdf
513912 2020-09-18 15:57 AT32UC3A364.atdf
523101 2020-09-18 15:57 AT32UC3A364S.atdf
515790 2020-09-18 15:57 AT32UC3A4128.atdf
524979 2020-09-18 15:57 AT32UC3A4128S.atdf
515790 2020-09-18 15:57 AT32UC3A4256.atdf
524979 2020-09-18 15:57 AT32UC3A4256S.atdf
513931 2020-09-18 15:57 AT32UC3A464.atdf
523120 2020-09-18 15:57 AT32UC3A464S.atdf
353307 2020-09-18 15:57 AT32UC3B0128.atdf
353306 2020-09-18 15:57 AT32UC3B0256.atdf
357446 2020-09-18 15:57 AT32UC3B0512.atdf
353305 2020-09-18 15:57 AT32UC3B064.atdf
337678 2020-09-18 15:57 AT32UC3B1128.atdf
337678 2020-09-18 15:57 AT32UC3B1256.atdf
356551 2020-09-18 15:57 AT32UC3B1512.atdf
337674 2020-09-18 15:57 AT32UC3B164.atdf
841945 2020-09-18 15:57 AT32UC3C0128C.atdf
838821 2020-09-18 15:57 AT32UC3C0256C.atdf
838918 2020-09-18 15:57 AT32UC3C0512C.atdf
838821 2020-09-18 15:57 AT32UC3C064C.atdf
827160 2020-09-18 15:57 AT32UC3C1128C.atdf
827161 2020-09-18 15:57 AT32UC3C1256C.atdf
827244 2020-09-18 15:57 AT32UC3C1512C.atdf
827161 2020-09-18 15:57 AT32UC3C164C.atdf
815056 2020-09-18 15:57 AT32UC3C2128C.atdf
815057 2020-09-18 15:57 AT32UC3C2256C.atdf
815140 2020-09-18 15:57 AT32UC3C2512C.atdf
815057 2020-09-18 15:57 AT32UC3C264C.atdf
607660 2020-09-18 15:57 AT32UC3L0128.atdf
489228 2020-09-18 15:57 AT32UC3L016.atdf
607429 2020-09-18 15:57 AT32UC3L0256.atdf
489351 2020-09-18 15:57 AT32UC3L032.atdf
512152 2020-09-18 15:57 AT32UC3L064.atdf
102904 2023-08-15 15:08 AT90CAN128.atdf
101282 2023-08-15 15:08 AT90CAN32.atdf
101402 2023-08-15 15:08 AT90CAN64.atdf
75537 2023-08-15 15:08 AT90PWM1.atdf
70469 2023-08-15 15:08 AT90PWM161.atdf
79625 2023-08-15 15:08 AT90PWM216.atdf
81495 2023-08-15 15:08 AT90PWM2B.atdf
88682 2023-08-15 15:08 AT90PWM3.atdf
86968 2023-08-15 15:08 AT90PWM316.atdf
87613 2023-08-15 15:08 AT90PWM3B.atdf
71631 2023-08-15 15:08 AT90PWM81.atdf
85865 2023-08-15 15:08 AT90USB1286.atdf
91745 2023-08-15 15:08 AT90USB1287.atdf
62628 2023-08-15 15:08 AT90USB162.atdf
91741 2023-08-15 15:08 AT90USB646.atdf
91741 2023-08-15 15:08 AT90USB647.atdf
62627 2023-08-15 15:08 AT90USB82.atdf
64885 2022-03-03 12:51 ATA5272.atdf
65106 2022-09-26 11:59 ATA5505.atdf
152085 2022-09-26 11:59 ATA5700M322.atdf
170156 2022-09-26 11:59 ATA5702M322.atdf
117293 2022-09-26 11:59 ATA5781.atdf
117534 2022-09-26 11:59 ATA5782.atdf
117531 2022-09-26 11:59 ATA5783.atdf
125819 2022-09-26 11:59 ATA5787.atdf
56337 2022-03-03 12:51 ATA5790.atdf
57771 2022-03-03 12:51 ATA5790N.atdf
57852 2022-03-03 12:51 ATA5791.atdf
48975 2022-03-03 12:51 ATA5795.atdf
128703 2022-09-26 11:59 ATA5831.atdf
128700 2022-09-26 11:59 ATA5832.atdf
128461 2022-09-26 11:59 ATA5833.atdf
137403 2022-09-26 11:59 ATA5835.atdf
47160 2022-03-03 12:51 ATA6285.atdf
47160 2022-03-03 12:51 ATA6286.atdf
67961 2022-03-03 12:51 ATA6612C.atdf
68149 2022-03-03 12:51 ATA6613C.atdf
68245 2022-03-03 12:51 ATA6614Q.atdf
64654 2022-03-03 12:51 ATA6616C.atdf
64654 2022-03-03 12:51 ATA6617C.atdf
64542 2022-03-03 12:51 ATA664251.atdf
117534 2022-09-26 11:59 ATA8210.atdf
117293 2022-09-26 11:59 ATA8215.atdf
128703 2022-09-26 11:59 ATA8510.atdf
128462 2022-09-26 11:59 ATA8515.atdf
361120 2020-09-18 15:59 ATBTLC1000WLCSP.atdf
89745 2023-08-15 15:08 ATmega128.atdf
129170 2023-08-15 15:08 ATmega1280.atdf
113892 2023-08-15 15:08 ATmega1281.atdf
93770 2023-08-15 15:08 ATmega1284.atdf
96851 2023-08-15 15:08 ATmega1284P.atdf
191773 2023-08-15 15:08 ATmega1284RFR2.atdf
88179 2023-08-15 15:08 ATmega128A.atdf
170953 2023-08-15 15:08 ATmega128RFA1.atdf
189862 2023-08-15 15:08 ATmega128RFR2.atdf
73320 2023-08-15 15:08 ATmega16.atdf
256354 2023-08-15 15:08 ATmega1608.atdf
267591 2023-08-15 15:08 ATmega1609.atdf
69975 2023-08-15 15:08 ATmega162.atdf
95062 2023-08-15 15:08 ATmega164A.atdf
92435 2023-08-15 15:08 ATmega164P.atdf
95692 2023-08-15 15:08 ATmega164PA.atdf
64542 2023-08-15 15:08 ATmega165A.atdf
64542 2023-08-15 15:08 ATmega165P.atdf
64684 2023-08-15 15:08 ATmega165PA.atdf
80348 2023-08-15 15:08 ATmega168.atdf
82474 2023-08-15 15:08 ATmega168A.atdf
81733 2023-08-15 15:08 ATmega168P.atdf
83129 2023-08-15 15:08 ATmega168PA.atdf
80648 2023-08-15 15:08 ATmega168PB.atdf
90370 2023-08-15 15:08 ATmega169A.atdf
90526 2023-08-15 15:08 ATmega169P.atdf
92317 2023-08-15 15:08 ATmega169PA.atdf
74627 2023-08-15 15:08 ATmega16A.atdf
42910 2023-08-15 15:08 ATmega16HVA.atdf
61665 2023-08-15 15:08 ATmega16HVB.atdf
61668 2023-08-15 15:08 ATmega16HVBrevB.atdf
101003 2023-08-15 15:08 ATmega16M1.atdf
74611 2023-08-15 15:08 ATmega16U2.atdf
98945 2023-08-15 15:08 ATmega16U4.atdf
129232 2023-08-15 15:08 ATmega2560.atdf
113427 2023-08-15 15:08 ATmega2561.atdf
190199 2023-08-15 15:08 ATmega2564RFR2.atdf
190138 2023-08-15 15:08 ATmega256RFR2.atdf
72648 2023-08-15 15:08 ATmega32.atdf
254148 2023-08-15 15:08 ATmega3208.atdf
265672 2023-08-15 15:08 ATmega3209.atdf
94915 2023-08-15 15:08 ATmega324A.atdf
92592 2023-08-15 15:08 ATmega324P.atdf
97031 2023-08-15 15:08 ATmega324PA.atdf
113019 2023-08-15 15:08 ATmega324PB.atdf
64567 2023-08-15 15:08 ATmega325.atdf
66380 2023-08-15 15:08 ATmega3250.atdf
66381 2023-08-15 15:08 ATmega3250A.atdf
66521 2023-08-15 15:08 ATmega3250P.atdf
66264 2023-08-15 15:08 ATmega3250PA.atdf
64723 2023-08-15 15:08 ATmega325A.atdf
64863 2023-08-15 15:08 ATmega325P.atdf
64663 2023-08-15 15:08 ATmega325PA.atdf
83077 2023-08-15 15:08 ATmega328.atdf
81596 2023-08-15 15:08 ATmega328P.atdf
98689 2023-08-15 15:08 ATmega328PB.atdf
86422 2023-08-15 15:08 ATmega329.atdf
72585 2023-08-15 15:08 ATmega3290.atdf
72586 2023-08-15 15:08 ATmega3290A.atdf
74662 2023-08-15 15:08 ATmega3290P.atdf
74261 2023-08-15 15:08 ATmega3290PA.atdf
99020 2023-08-15 15:08 ATmega329A.atdf
100704 2023-08-15 15:08 ATmega329P.atdf
99165 2023-08-15 15:08 ATmega329PA.atdf
70893 2023-08-15 15:08 ATmega32A.atdf
92499 2023-08-15 15:08 ATmega32C1.atdf
61665 2023-08-15 15:08 ATmega32HVB.atdf
57876 2023-08-15 15:08 ATmega32HVBrevB.atdf
98242 2023-08-15 15:08 ATmega32M1.atdf
73269 2023-08-15 15:08 ATmega32U2.atdf
96445 2023-08-15 15:08 ATmega32U4.atdf
51809 2023-08-15 15:08 ATmega406.atdf
79684 2023-08-15 15:08 ATmega48.atdf
254281 2023-08-15 15:08 ATmega4808.atdf
265805 2023-08-15 15:08 ATmega4809.atdf
80645 2023-08-15 15:08 ATmega48A.atdf
79603 2023-08-15 15:08 ATmega48P.atdf
81445 2023-08-15 15:08 ATmega48PA.atdf
78333 2023-08-15 15:08 ATmega48PB.atdf
90121 2023-08-15 15:08 ATmega64.atdf
128753 2023-08-15 15:08 ATmega640.atdf
87165 2023-08-15 15:08 ATmega644.atdf
89942 2023-08-15 15:08 ATmega644A.atdf
91509 2023-08-15 15:08 ATmega644P.atdf
90419 2023-08-15 15:08 ATmega644PA.atdf
189377 2023-08-15 15:08 ATmega644RFR2.atdf
64368 2023-08-15 15:08 ATmega645.atdf
65970 2023-08-15 15:08 ATmega6450.atdf
65971 2023-08-15 15:08 ATmega6450A.atdf
65971 2023-08-15 15:08 ATmega6450P.atdf
64446 2023-08-15 15:08 ATmega645A.atdf
64586 2023-08-15 15:08 ATmega645P.atdf
86034 2023-08-15 15:08 ATmega649.atdf
72005 2023-08-15 15:08 ATmega6490.atdf
72006 2023-08-15 15:08 ATmega6490A.atdf
72006 2023-08-15 15:08 ATmega6490P.atdf
85740 2023-08-15 15:08 ATmega649A.atdf
85739 2023-08-15 15:08 ATmega649P.atdf
89521 2023-08-15 15:08 ATmega64A.atdf
90287 2023-08-15 15:08 ATmega64C1.atdf
59960 2023-08-15 15:08 ATmega64HVE2.atdf
98280 2023-08-15 15:08 ATmega64M1.atdf
187754 2023-08-15 15:08 ATmega64RFR2.atdf
65718 2023-08-15 15:08 ATmega8.atdf
256350 2023-08-15 15:08 ATmega808.atdf
267588 2023-08-15 15:08 ATmega809.atdf
52857 2023-08-15 15:08 ATmega8515.atdf
59606 2023-08-15 15:08 ATmega8535.atdf
80336 2023-08-15 15:08 ATmega88.atdf
82463 2023-08-15 15:08 ATmega88A.atdf
81544 2023-08-15 15:08 ATmega88P.atdf
83262 2023-08-15 15:08 ATmega88PA.atdf
80638 2023-08-15 15:08 ATmega88PB.atdf
65046 2023-08-15 15:08 ATmega8A.atdf
42909 2023-08-15 15:08 ATmega8HVA.atdf
73258 2023-08-15 15:08 ATmega8U2.atdf
25951 2023-08-16 20:04 ATtiny10.atdf
36953 2023-08-16 20:04 ATtiny102.atdf
38024 2023-08-16 20:04 ATtiny104.atdf
17424 2023-08-16 20:04 ATtiny11.atdf
25497 2023-08-16 20:04 ATtiny12.atdf
40474 2023-08-16 20:04 ATtiny13.atdf
41199 2023-08-16 20:04 ATtiny13A.atdf
31285 2023-08-16 20:04 ATtiny15.atdf
218792 2023-08-16 20:04 ATtiny1604.atdf
226516 2023-08-16 20:04 ATtiny1606.atdf
228319 2023-08-16 20:04 ATtiny1607.atdf
266347 2023-08-16 20:04 ATtiny1614.atdf
276034 2023-08-16 20:04 ATtiny1616.atdf
278997 2023-08-16 20:04 ATtiny1617.atdf
251881 2023-08-16 20:04 ATtiny1624.atdf
260745 2023-08-16 20:04 ATtiny1626.atdf
264642 2023-08-16 20:04 ATtiny1627.atdf
61199 2023-08-16 20:04 ATtiny1634.atdf
64391 2023-08-16 20:04 ATtiny167.atdf
43366 2023-08-16 20:04 ATtiny20.atdf
211016 2023-08-16 20:04 ATtiny202.atdf
220893 2023-08-16 20:04 ATtiny204.atdf
245158 2023-08-16 20:04 ATtiny212.atdf
253873 2023-08-16 20:04 ATtiny214.atdf
49382 2023-08-16 20:04 ATtiny2313.atdf
50623 2023-08-16 20:04 ATtiny2313A.atdf
49454 2023-08-16 20:04 ATtiny24.atdf
56821 2023-08-16 20:04 ATtiny24A.atdf
58038 2023-08-16 20:04 ATtiny25.atdf
45529 2023-08-16 20:04 ATtiny26.atdf
65685 2023-08-16 20:04 ATtiny261.atdf
58264 2023-08-16 20:04 ATtiny261A.atdf
280677 2023-08-16 20:04 ATtiny3216.atdf
284985 2023-08-16 20:04 ATtiny3217.atdf
251881 2023-08-16 20:04 ATtiny3224.atdf
260745 2023-08-16 20:04 ATtiny3226.atdf
264642 2023-08-16 20:04 ATtiny3227.atdf
22250 2023-08-16 20:04 ATtiny4.atdf
42154 2023-08-16 20:04 ATtiny40.atdf
211019 2023-08-16 20:04 ATtiny402.atdf
220896 2023-08-16 20:04 ATtiny404.atdf
226849 2023-08-16 20:04 ATtiny406.atdf
245161 2023-08-16 20:04 ATtiny412.atdf
253876 2023-08-16 20:04 ATtiny414.atdf
261964 2023-08-16 20:04 ATtiny416.atdf
260908 2022-09-26 11:59 ATtiny416auto.atdf
265391 2023-08-16 20:04 ATtiny417.atdf
251878 2023-08-16 20:04 ATtiny424.atdf
260742 2023-08-16 20:04 ATtiny426.atdf
264639 2023-08-16 20:04 ATtiny427.atdf
50605 2023-08-16 20:04 ATtiny4313.atdf
50540 2023-08-16 20:04 ATtiny43U.atdf
49452 2023-08-16 20:04 ATtiny44.atdf
78149 2023-08-16 20:04 ATtiny441.atdf
56671 2023-08-16 20:04 ATtiny44A.atdf
56991 2023-08-16 20:04 ATtiny45.atdf
65681 2023-08-16 20:04 ATtiny461.atdf
58261 2023-08-16 20:04 ATtiny461A.atdf
62483 2023-08-16 20:04 ATtiny48.atdf
25953 2023-08-16 20:04 ATtiny5.atdf
218788 2023-08-16 20:04 ATtiny804.atdf
226510 2023-08-16 20:04 ATtiny806.atdf
228315 2023-08-16 20:04 ATtiny807.atdf
255570 2023-08-16 20:04 ATtiny814.atdf
263845 2023-08-16 20:04 ATtiny816.atdf
265647 2023-08-16 20:04 ATtiny817.atdf
251878 2023-08-16 20:04 ATtiny824.atdf
260742 2023-08-16 20:04 ATtiny826.atdf
264639 2023-08-16 20:04 ATtiny827.atdf
63952 2023-08-16 20:04 ATtiny828.atdf
49452 2023-08-16 20:04 ATtiny84.atdf
78149 2023-08-16 20:04 ATtiny841.atdf
56378 2023-08-16 20:04 ATtiny84A.atdf
56676 2023-08-16 20:04 ATtiny85.atdf
65887 2023-08-16 20:04 ATtiny861.atdf
58382 2023-08-16 20:04 ATtiny861A.atdf
64391 2023-08-16 20:04 ATtiny87.atdf
62484 2023-08-16 20:04 ATtiny88.atdf
22250 2023-08-16 20:04 ATtiny9.atdf
705933 2020-09-18 15:57 ATUC128D3.atdf
706887 2020-09-18 15:57 ATUC128D4.atdf
766531 2020-09-18 15:57 ATUC128L3U.atdf
747722 2020-09-18 15:57 ATUC128L4U.atdf
766527 2020-09-18 15:57 ATUC256L3U.atdf
747718 2020-09-18 15:57 ATUC256L4U.atdf
705967 2020-09-18 15:57 ATUC64D3.atdf
705091 2020-09-18 15:57 ATUC64D4.atdf
766519 2020-09-18 15:57 ATUC64L3U.atdf
747715 2020-09-18 15:57 ATUC64L4U.atdf
194011 2023-08-14 15:03 ATxmega128A1.atdf
258859 2023-08-14 15:03 ATxmega128A1U.atdf
176060 2023-08-14 15:03 ATxmega128A3.atdf
232603 2023-08-14 15:03 ATxmega128A3U.atdf
223401 2023-08-14 15:03 ATxmega128A4U.atdf
215389 2023-01-09 13:05 ATxmega128B1.atdf
204355 2023-01-09 13:05 ATxmega128B3.atdf
185046 2023-08-14 14:56 ATxmega128C3.atdf
169097 2023-08-14 14:56 ATxmega128D3.atdf
168273 2023-08-14 14:56 ATxmega128D4.atdf
172821 2023-08-14 15:03 ATxmega16A4.atdf
222677 2023-08-14 15:03 ATxmega16A4U.atdf
183672 2023-08-14 14:56 ATxmega16C4.atdf
166398 2023-08-14 14:56 ATxmega16D4.atdf
225287 2023-08-14 14:56 ATxmega16E5.atdf
176193 2023-08-14 15:03 ATxmega192A3.atdf
232612 2023-08-14 15:03 ATxmega192A3U.atdf
168651 2023-08-14 14:56 ATxmega192C3.atdf
168958 2023-08-14 14:56 ATxmega192D3.atdf
175951 2023-08-14 15:03 ATxmega256A3.atdf
176580 2023-08-14 15:03 ATxmega256A3B.atdf
228458 2023-08-14 15:03 ATxmega256A3BU.atdf
232604 2023-08-14 15:03 ATxmega256A3U.atdf
185043 2023-08-14 14:56 ATxmega256C3.atdf
168815 2023-08-14 14:56 ATxmega256D3.atdf
172687 2023-08-14 15:03 ATxmega32A4.atdf
222732 2023-08-14 15:03 ATxmega32A4U.atdf
185035 2023-08-14 14:56 ATxmega32C3.atdf
183672 2023-08-14 14:56 ATxmega32C4.atdf
168846 2023-08-14 14:56 ATxmega32D3.atdf
166410 2023-08-14 14:56 ATxmega32D4.atdf
225288 2023-08-14 14:56 ATxmega32E5.atdf
201318 2023-08-14 14:56 ATxmega384C3.atdf
172214 2023-08-14 14:56 ATxmega384D3.atdf
194016 2023-08-14 15:03 ATxmega64A1.atdf
258859 2023-08-14 15:03 ATxmega64A1U.atdf
176057 2023-08-14 15:03 ATxmega64A3.atdf
232599 2023-08-14 15:03 ATxmega64A3U.atdf
223387 2023-08-14 15:03 ATxmega64A4U.atdf
215207 2023-01-09 13:05 ATxmega64B1.atdf
204205 2023-01-09 13:05 ATxmega64B3.atdf
185042 2023-08-14 14:56 ATxmega64C3.atdf
168956 2023-08-14 14:56 ATxmega64D3.atdf
167493 2023-08-14 14:56 ATxmega64D4.atdf
225281 2023-08-14 14:56 ATxmega8E5.atdf
325266 2022-12-16 13:03 AVR128DA28.atdf
332632 2022-12-16 13:03 AVR128DA32.atdf
399474 2022-12-16 13:03 AVR128DA48.atdf
428558 2022-12-16 13:03 AVR128DA64.atdf
351053 2022-12-16 13:03 AVR128DB28.atdf
357383 2022-12-16 13:03 AVR128DB32.atdf
433083 2022-12-16 13:03 AVR128DB48.atdf
457073 2022-12-16 13:03 AVR128DB64.atdf
309618 2022-12-16 13:03 AVR16DD14.atdf
319440 2022-12-16 13:03 AVR16DD20.atdf
327339 2022-12-16 13:03 AVR16DD28.atdf
331274 2022-12-16 13:03 AVR16DD32.atdf
298102 2023-10-02 14:18 AVR16EA28.atdf
302717 2023-10-02 14:18 AVR16EA32.atdf
321483 2023-10-02 14:18 AVR16EA48.atdf
316823 2023-10-02 14:18 AVR16EB14.atdf
330738 2023-10-02 14:18 AVR16EB20.atdf
337209 2023-10-02 14:18 AVR16EB28.atdf
340082 2023-10-02 14:18 AVR16EB32.atdf
324634 2022-12-16 13:03 AVR32DA28.atdf
332000 2022-12-16 13:03 AVR32DA32.atdf
398842 2022-12-16 13:03 AVR32DA48.atdf
350849 2022-12-16 13:03 AVR32DB28.atdf
357179 2022-12-16 13:03 AVR32DB32.atdf
432879 2022-12-16 13:03 AVR32DB48.atdf
309619 2022-12-16 13:03 AVR32DD14.atdf
319441 2022-12-16 13:03 AVR32DD20.atdf
327340 2022-12-16 13:03 AVR32DD28.atdf
331275 2022-12-16 13:03 AVR32DD32.atdf
298103 2023-10-02 14:18 AVR32EA28.atdf
302718 2023-10-02 14:18 AVR32EA32.atdf
321484 2023-10-02 14:18 AVR32EA48.atdf
325064 2022-12-16 13:03 AVR64DA28.atdf
332430 2022-12-16 13:03 AVR64DA32.atdf
399272 2022-12-16 13:03 AVR64DA48.atdf
428356 2022-12-16 13:03 AVR64DA64.atdf
350851 2022-12-16 13:03 AVR64DB28.atdf
357181 2022-12-16 13:03 AVR64DB32.atdf
432881 2022-12-16 13:03 AVR64DB48.atdf
456871 2022-12-16 13:03 AVR64DB64.atdf
309621 2022-12-16 13:03 AVR64DD14.atdf
319443 2022-12-16 13:03 AVR64DD20.atdf
327342 2022-12-16 13:03 AVR64DD28.atdf
331277 2022-12-16 13:03 AVR64DD32.atdf
298105 2023-10-02 14:18 AVR64EA28.atdf
302720 2023-10-02 14:18 AVR64EA32.atdf
321486 2023-10-02 14:18 AVR64EA48.atdf
428426 2020-09-18 16:00 WLR089U0.atdf@stefanrueger
Sorry but just wondering if you have a tip to parse the atdf files to show that only the AVR EA and EB family AVRs are using NVM v3. Thanks.
I am family with simple bash commands but never really go into details. I usually just use Google if I need to use a more comples command, for example, the above ls *.atdf -laG --time-style=long-iso | awk '{print $4, $5, $6, $7}' command.
mcuee
commented
1 year ago I would like to thank you all for your great work.
The attached code is a program that allows you to experience sleep failures (rather than address width issues). This applies to tinyAVR-2 and most of its AVR_DA/DB/DD/EA/EB. It can be constructed with AVR-LIBC.
When I run it, the LED keeps blinking using PA7, but the CPU remains in a STANDBY sleep state with interrupts disabled. Also, F_CPU is 512Hz.
(TCB0, CCL, and EVOUT are used for this LED blinking operation, but tinyAVR-0/1 and megaAVR-0 are not supported because the difference in CCL is troublesome.)
Please upload your code to the device using a method other than the problematic SerialUPDI and test it with SerialUPDI. It is important not to reset the CPU at this point. The CPU startup start time is affected by the SUT setting value of FUSE_SYSCFG1.
To test without going to sleep, run a SerialUPDI with the reset pad LOW, wait a second or two, then release the reset. SerialUPDI should be able to recognize the CPU. A power-on reset is required if the chip's reset pad functionality is disabled in FUSE_SYSCFG0.
I think I can reproduce the issue just using serialupdi.
You can see programming is okay.
But then running simple query command with -c will fail as that does not reset the MCU.
I am using latest git main which has PR #1531 merged.
PS C:\work\avr\avrdude_test\avrdude_bin> cat .\Makefile
CFLAGS ?= -Os -DF_APU=512UL -mmcu=avr32dd14
LDFLAGS ?= -mmcu=avr32dd14
all: sleep.hex
sleep.hex: sleep.elf
avr-objcopy -O ihex sleep.elf sleep.hex
sleep.elf: sleep.o
avr-gcc $(LDFLAGS) -o $@ $^
sleep.o: sleep.c
avr-gcc $(CFLAGS) -c -o $@ $<
clean: FRC
rm -f sleep.elf sleep.hex sleep.o
FRC:
PS C:\work\avr\avrdude_test\avrdude_bin> make
avr-gcc -Os -DF_APU=512UL -mmcu=avr32dd14 -c -o sleep.o sleep.c
avr-gcc -mmcu=avr32dd14 -o sleep.elf sleep.o
avr-objcopy -O ihex sleep.elf sleep.hex
PS C:\work\avr\avrdude_test\avrdude_bin> function prompt {$null}
PS>.\avrdude_git -c serialupdi -P COM11 -p avr32dd14 -U .\sleep.hex
avrdude_git: AVR device initialized and ready to accept instructions
avrdude_git: device signature = 0x1e953b (probably avr32dd14)
avrdude_git: Note: flash memory has been specified, an erase cycle will be performed.
To disable this feature, specify the -D option.
avrdude_git: erasing chip
avrdude_git: processing -U flash:w:.\sleep.hex:i
avrdude_git: reading input file .\sleep.hex for flash
with 276 bytes in 1 section within [0, 0x113]
using 1 page and 236 pad bytes
avrdude_git: writing 276 bytes flash ...
Writing | ################################################## | 100% 0.16 s
avrdude_git: 276 bytes of flash written
avrdude_git: verifying flash memory against .\sleep.hex
Reading | ################################################## | 100% 0.07 s
avrdude_git: 276 bytes of flash verified
avrdude_git done. Thank you.Hmm, strange. Using -v will fail. Without -v it will be good.
stefanrueger
commented
1 year ago Using -v will fail. Without -v it will be good.
I suspect just one -v is OK, but -vvvv might ruin the timing of commands by the time it takes to print. Try to log on RAM, eg, -vvvvl/dev/shm/error.log
stefanrueger
commented
1 year ago parse the atdf files to show that only the AVR EA and EB family AVRs are using NVM v3
Do you know how ATDF encodes this? xml_grep is useful
xml_grep -g --pretty_print indented --cond 'module[@name="NVMCTRL"]' *.atdfreduces the amount to look at
mcuee
commented
1 year ago Using -v will fail. Without -v it will be good.
I suspect just one -v is OK, but -vvvv might ruin the timing of commands by the time it takes to print. Try to log on RAM, eg, -vvvvl/dev/shm/error.log
One -v is already causing problems. Please refer to the log posted earlier.
PS>.\avrdude_git -c serialupdi -P COM11 -p avr32dd14 -U .\sleep.hex -v
avrdude_git: Version 7.2-20231018 (481a91dd)
Copyright the AVRDUDE authors;
see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is C:\work\avr\avrdude_test\avrdude_bin\avrdude.conf
Using Port : COM11
Using Programmer : serialupdi
avrdude_git: input file .\sleep.hex auto detected as Intel Hex
AVR Part : AVR32DD14
RESET disposition : dedicated
RETRY pulse : SCK
Serial program mode : yes
Parallel program mode : yes
Memory Detail :
...
...
Programmer Type : serialupdi
Description : SerialUPDI
avrdude_git serialupdi_initialize() error: UPDI link initialization failed
avrdude_git main() error: initialization failed, rc=-1
- double check the connections and try again
- use -b to set lower baud rate, e.g. -b 57600
- use -F to override this check
avrdude_git: leaving NVM programming mode
avrdude_git done. Thank you.Hmm, I can not reproduce the issue on ATtiny3227.
mcuee
commented
1 year ago Using -v will fail. Without -v it will be good.
I suspect just one -v is OK, but -vvvv might ruin the timing of commands by the time it takes to print. Try to log on RAM, eg, -vvvvl/dev/shm/error.log
One
-vis already causing problems. Please refer to the log posted earlier.
Same for another AVR64DD32 board. One -v and it will fail. This one has the LED and I can see the Sleep FW is working.
PS>make -f .\Makefile_avr64dd32
avr-gcc -Os -DF_APU=512UL -mmcu=avr64dd32 -c -o sleep.o sleep.c
avr-gcc -mmcu=avr64dd32 -o sleep.elf sleep.o
avr-objcopy -O ihex sleep.elf sleep.hex
PS>.\avrdude_git -c serialupdi -P COM11 -p avr64dd32 -U .\sleep.hex
avrdude_git: AVR device initialized and ready to accept instructions
avrdude_git: device signature = 0x1e961a (probably avr64dd32)
avrdude_git: Note: flash memory has been specified, an erase cycle will be performed.
To disable this feature, specify the -D option.
avrdude_git: erasing chip
avrdude_git: processing -U flash:w:.\sleep.hex:i
avrdude_git: reading input file .\sleep.hex for flash
with 276 bytes in 1 section within [0, 0x113]
using 1 page and 236 pad bytes
avrdude_git: writing 276 bytes flash ...
Writing | ################################################## | 100% 0.16 s
avrdude_git: 276 bytes of flash written
avrdude_git: verifying flash memory against .\sleep.hex
Reading | ################################################## | 100% 0.07 s
avrdude_git: 276 bytes of flash verified
avrdude_git done. Thank you.
PS>.\avrdude_git -c serialupdi -P COM11 -p avr64dd32
avrdude_git: AVR device initialized and ready to accept instructions
avrdude_git: device signature = 0x1e961a (probably avr64dd32)
avrdude_git done. Thank you.
PS>.\avrdude_git -c serialupdi -P COM11 -p avr64dd32 -v
avrdude_git: Version 7.2-20231018 (481a91dd)
Copyright the AVRDUDE authors;
see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is C:\work\avr\avrdude_test\avrdude_bin\avrdude.conf
Using Port : COM11
Using Programmer : serialupdi
AVR Part : AVR64DD32
RESET disposition : dedicated
RETRY pulse : SCK
Serial program mode : yes
Parallel program mode : yes
Memory Detail :
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
fuse0 wdtcfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse1 bodcfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse2 osccfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse5 syscfg0 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse6 syscfg1 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse7 codesize 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse8 bootsize 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuses 0 0 0 0 no 16 16 0 0 0 0x00 0x00
lock 0 0 0 0 no 4 1 0 0 0 0x00 0x00
prodsig sigrow 0 0 0 0 no 128 128 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 1 0 0 0 0x00 0x00
tempsense 0 0 0 0 no 4 1 0 0 0 0x00 0x00
sernum 0 0 0 0 no 16 1 0 0 0 0x00 0x00
userrow usersig 0 0 0 0 no 32 32 0 0 0 0x00 0x00
data 0 0 0 0 no 0 1 0 0 0 0x00 0x00
io 0 0 0 0 no 4160 1 0 0 0 0x00 0x00
sib 0 0 0 0 no 32 1 0 0 0 0x00 0x00
eeprom 0 0 0 0 no 256 1 0 0 0 0x00 0x00
flash 0 0 0 0 no 65536 512 0 0 0 0x00 0x00
Programmer Type : serialupdi
Description : SerialUPDI
avrdude_git serialupdi_initialize() error: UPDI link initialization failed
avrdude_git main() error: initialization failed, rc=-1
- double check the connections and try again
- use -b to set lower baud rate, e.g. -b 57600
- use -F to override this check
avrdude_git: leaving NVM programming mode
avrdude_git done. Thank you.Using -v will fail. Without -v it will be good.
I suspect just one -v is OK, but -vvvv might ruin the timing of commands by the time it takes to print. Try to log on RAM, eg, -vvvvl/dev/shm/error.log
I think you are right that the timing is affected which may cause failures.
It is okay if I redirect the log with -v. But -vvvv will still fail. I do not have /dev/shm under Windows PowerShell.
P> .\avrdude_git -c serialupdi -P COM11 -p avr64dd32 -v >error.log 2>&1
PS>cat .\error.log
avrdude_git: Version 7.2-20231018 (481a91dd)
...
Programmer Type : serialupdi
Description : SerialUPDI
avrdude_git: device is in SLEEP mode
avrdude_git: NVM type 2: 24-bit, word oriented write
avrdude_git: Chip silicon revision: 1.3
avrdude_git: entering NVM programming mode
avrdude_git: AVR device initialized and ready to accept instructions
avrdude_git: device signature = 0x1e961a (probably avr64dd32)
avrdude_git: leaving NVM programming mode
avrdude_git done. Thank you.
PS>.\avrdude_git -c serialupdi -P COM11 -p avr64dd32 -vvvv >errorvvvv.log 2>&1
PS>cat .\errorvvvv.log
avrdude_git: Version 7.2-20231018 (481a91dd)
Copyright the AVRDUDE authors;
see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is C:\work\avr\avrdude_test\avrdude_bin\avrdude.conf
Using Port : COM11
Using Programmer : serialupdi
avrdude_git: opening serial port ...
avrdude_git: sending 1 bytes [0x00]
avrdude_git: send: . [00]
avrdude_git: recv: . [00]
AVR Part : AVR64DD32
RESET disposition : dedicated
RETRY pulse : SCK
Serial program mode : yes
Parallel program mode : yes
...
Programmer Type : serialupdi
Description : SerialUPDI
avrdude_git: STCS 0x08 to address 0x03
avrdude_git: sending 3 bytes [0x55, 0xc3, 0x08]
avrdude_git: send: U [55] . [c3] . [08]
avrdude_git: ser_recv(): programmer is not responding
avrdude_git: STCS 0x80 to address 0x02
avrdude_git: sending 3 bytes [0x55, 0xc2, 0x80]
avrdude_git: send: U [55] . [c2] . [80]
avrdude_git: ser_recv(): programmer is not responding
avrdude_git: LDCS from 0x00
avrdude_git: sending 2 bytes [0x55, 0x80]
avrdude_git: send: U [55] . [80]
avrdude_git: ser_recv(): programmer is not responding
avrdude_git: ser_recv(): programmer is not responding
avrdude_git: serialupdi_recv(): programmer is not responding
avrdude_git: check failed
avrdude_git: datalink not active, resetting ...
avrdude_git: sending double break
avrdude_git: send: . [00]
avrdude_git: recv: . [00]
avrdude_git: send: . [00]
avrdude_git: recv: . [00]
avrdude_git: STCS 0x08 to address 0x03
avrdude_git: sending 3 bytes [0x55, 0xc3, 0x08]
avrdude_git: send: U [55] . [c3] . [08]
avrdude_git: ser_recv(): programmer is not responding
avrdude_git: STCS 0x80 to address 0x02
avrdude_git: sending 3 bytes [0x55, 0xc2, 0x80]
avrdude_git: send: U [55] . [c2] . [80]
avrdude_git: ser_recv(): programmer is not responding
avrdude_git: LDCS from 0x00
avrdude_git: sending 2 bytes [0x55, 0x80]
avrdude_git: send: U [55] . [80]
avrdude_git: ser_recv(): programmer is not responding
avrdude_git: ser_recv(): programmer is not responding
avrdude_git: serialupdi_recv(): programmer is not responding
avrdude_git: check failed
avrdude_git: restoring datalink failed
avrdude_git serialupdi_initialize() [serialupdi.c:569] error: UPDI link initialization failed
avrdude_git main() [main.c:1404] error: initialization failed, rc=-1
- double check the connections and try again
- use -b to set lower baud rate, e.g. -b 57600
- use -F to override this check
avrdude_git: leaving NVM programming mode
avrdude_git: sending reset request
avrdude_git: STCS 0x59 to address 0x08
avrdude_git: sending 3 bytes [0x55, 0xc8, 0x59]
avrdude_git: send: U [55] . [c8] Y [59]
avrdude_git: ser_recv(): programmer is not responding
avrdude_git: sending release reset request
avrdude_git: STCS 0x00 to address 0x08
avrdude_git: sending 3 bytes [0x55, 0xc8, 0x00]
avrdude_git: send: U [55] . [c8] . [00]
avrdude_git: ser_recv(): programmer is not responding
avrdude_git: STCS 0x0C to address 0x03
avrdude_git: sending 3 bytes [0x55, 0xc3, 0x0c]
avrdude_git: send: U [55] . [c3] . [0c]
avrdude_git: ser_recv(): programmer is not responding
avrdude_git done. Thank you.MSYS2 terminal has /dev/shm but it does not help. -v will be okay, -vv and -vvvv will fail.
MINGW64 /c/work/avr/avrdude_test/avrdude_bin
$ ./avrdude_git -c serialupdi -P COM11 -p avr64dd32 -vvvv > /dev/shm/errorvvvv.log 2>&1
$ cat /dev/shm/errorvvvv.log
avrdude_git: Version 7.2-20231018 (481a91dd)
...
Programmer Type : serialupdi
Description : SerialUPDI
avrdude_git: STCS 0x08 to address 0x03
avrdude_git: sending 3 bytes [0x55, 0xc3, 0x08]
avrdude_git: send: U [55] . [c3] . [08]
avrdude_git: ser_recv(): programmer is not responding
avrdude_git: STCS 0x80 to address 0x02
avrdude_git: sending 3 bytes [0x55, 0xc2, 0x80]
avrdude_git: send: U [55] . [c2] . [80]
avrdude_git: ser_recv(): programmer is not responding
avrdude_git: LDCS from 0x00
avrdude_git: sending 2 bytes [0x55, 0x80]
avrdude_git: send: U [55] . [80]
avrdude_git: ser_recv(): programmer is not responding
avrdude_git: ser_recv(): programmer is not responding
avrdude_git: serialupdi_recv(): programmer is not responding
avrdude_git: check failed
avrdude_git: datalink not active, resetting ...
avrdude_git: sending double break
avrdude_git: send: . [00]
avrdude_git: recv: . [00]
avrdude_git: send: . [00]
avrdude_git: recv: . [00]
avrdude_git: STCS 0x08 to address 0x03
avrdude_git: sending 3 bytes [0x55, 0xc3, 0x08]
avrdude_git: send: U [55] . [c3] . [08]
avrdude_git: ser_recv(): programmer is not responding
avrdude_git: STCS 0x80 to address 0x02
avrdude_git: sending 3 bytes [0x55, 0xc2, 0x80]
avrdude_git: send: U [55] . [c2] . [80]
avrdude_git: ser_recv(): programmer is not responding
avrdude_git: LDCS from 0x00
avrdude_git: sending 2 bytes [0x55, 0x80]
avrdude_git: send: U [55] . [80]
avrdude_git: ser_recv(): programmer is not responding
avrdude_git: ser_recv(): programmer is not responding
avrdude_git: serialupdi_recv(): programmer is not responding
avrdude_git: check failed
avrdude_git: restoring datalink failed
avrdude_git serialupdi_initialize() [serialupdi.c:569] error: UPDI link initialization failed
avrdude_git main() [main.c:1404] error: initialization failed, rc=-1
- double check the connections and try again
- use -b to set lower baud rate, e.g. -b 57600
- use -F to override this check
avrdude_git: leaving NVM programming mode
avrdude_git: sending reset request
avrdude_git: STCS 0x59 to address 0x08
avrdude_git: sending 3 bytes [0x55, 0xc8, 0x59]
avrdude_git: send: U [55] . [c8] Y [59]
avrdude_git: ser_recv(): programmer is not responding
avrdude_git: sending release reset request
avrdude_git: STCS 0x00 to address 0x08
avrdude_git: sending 3 bytes [0x55, 0xc8, 0x00]
avrdude_git: send: U [55] . [c8] . [00]
avrdude_git: ser_recv(): programmer is not responding
avrdude_git: STCS 0x0C to address 0x03
avrdude_git: sending 3 bytes [0x55, 0xc3, 0x0c]
avrdude_git: send: U [55] . [c3] . [0c]
avrdude_git: ser_recv(): programmer is not responding
avrdude_git done. Thank you.parse the atdf files to show that only the AVR EA and EB family AVRs are using NVM v3
Do you know how ATDF encodes this?
xml_grepis usefulxml_grep -g --pretty_print indented --cond 'module[@name="NVMCTRL"]' *.atdfreduces the amount to look at
Thanks for the tip. I tried to install xml_grep by using the command cpan install XML::Twig under MSYS2 but it failed.
Guess it is easier use Linux or macOS for this task.
But I will try under Windows using Strawberry Perl.
mcuee
commented
1 year ago Thanks for the tip. I tried to install xml_grep by using the command
cpan install XML::Twigunder MSYS2 but it failed.Guess it is easier use Linux or macOS for this task.
But I will try under Windows using Strawberry Perl.
Strawberry Perl has the module with the default installation, but it does not seem to work.
PS C:\work\avr\avrdude_test\atdf> xml_grep -g --pretty_print indented --cond 'module[@name="NVMCTRL"]' *.atdf
Couldn't open *.atdf:
Invalid argument at C:\Strawberry\perl\bin\xml_grep.bat line 149.
at C:\Strawberry\perl\bin\xml_grep.bat line 149.
<!-- error parsing file '*.atdf' -->Do you know how ATDF encodes this?
xml_grepis usefulxml_grep -g --pretty_print indented --cond 'module[@name="NVMCTRL"]' *.atdfreduces the amount to look at
Guess it is easier use Linux or macOS for this task.
Indeed it is quite easy to install xml-twig-tools under Ubuntu 20.04 and it works perfectly.
mcuee@UbuntuSwift3 ~/build/avr/atdf
$ xml_grep -g --pretty_print indented --cond 'module[@id="nvm_ctrl_avr_v3"]' *.atdf | grep filename
<file filename="AVR16EA28.atdf">
<file filename="AVR16EA32.atdf">
<file filename="AVR16EA48.atdf">
<file filename="AVR16EB14.atdf">
<file filename="AVR16EB20.atdf">
<file filename="AVR16EB28.atdf">
<file filename="AVR16EB32.atdf">
<file filename="AVR32EA28.atdf">
<file filename="AVR32EA32.atdf">
<file filename="AVR32EA48.atdf">
<file filename="AVR64EA28.atdf">
<file filename="AVR64EA32.atdf">
<file filename="AVR64EA48.atdf">
$ xml_grep -g --pretty_print indented --cond 'module[@id="nvm_ctrl_avr_v2"]' *.atdf | grep filename
<file filename="ATtiny1624.atdf">
<file filename="ATtiny1626.atdf">
<file filename="ATtiny1627.atdf">
<file filename="ATtiny3224.atdf">
<file filename="ATtiny3226.atdf">
<file filename="ATtiny3227.atdf">
<file filename="ATtiny424.atdf">
<file filename="ATtiny426.atdf">
<file filename="ATtiny427.atdf">
<file filename="ATtiny824.atdf">
<file filename="ATtiny826.atdf">
<file filename="ATtiny827.atdf">
$ xml_grep -g --pretty_print indented --cond 'module[@id="nvm_ctrl_avr_v1"]' *.atdf | grep filename
<file filename="AVR128DA28.atdf">
<file filename="AVR128DA32.atdf">
<file filename="AVR128DA48.atdf">
<file filename="AVR128DA64.atdf">
<file filename="AVR128DB28.atdf">
<file filename="AVR128DB32.atdf">
<file filename="AVR128DB48.atdf">
<file filename="AVR128DB64.atdf">
<file filename="AVR16DD14.atdf">
<file filename="AVR16DD20.atdf">
<file filename="AVR16DD28.atdf">
<file filename="AVR16DD32.atdf">
<file filename="AVR32DA28.atdf">
<file filename="AVR32DA32.atdf">
<file filename="AVR32DA48.atdf">
<file filename="AVR32DB28.atdf">
<file filename="AVR32DB32.atdf">
<file filename="AVR32DB48.atdf">
<file filename="AVR32DD14.atdf">
<file filename="AVR32DD20.atdf">
<file filename="AVR32DD28.atdf">
<file filename="AVR32DD32.atdf">
<file filename="AVR64DA28.atdf">
<file filename="AVR64DA32.atdf">
<file filename="AVR64DA48.atdf">
<file filename="AVR64DA64.atdf">
<file filename="AVR64DB28.atdf">
<file filename="AVR64DB32.atdf">
<file filename="AVR64DB48.atdf">
<file filename="AVR64DB64.atdf">
<file filename="AVR64DD14.atdf">
<file filename="AVR64DD20.atdf">
<file filename="AVR64DD28.atdf">
<file filename="AVR64DD32.atdf">Hello, I just wanted to apologise for not contributing to the investigation - I have a very tough week at work and no energy to look into it in my spare time.
@mcuee Thank you very much for trying to replicate the issue and for providing detailed instructions regarding build and testing of the code in question. I will look into as soon as I have the time and energy to do so. As for the actual resolution - looking at the logs I can see that the UPDI controller doesn't seem to be responding at all, so this might be tough nut to crack, but I will do my best to find out how to handle this.
mcuee
commented
1 year ago @dbuchwald
Take your time and thanks for your great contribution to avrdude project. We all do this at our spare time and paid job is always more important.
dbuchwald
commented
1 year ago Guys, I need some help/guidance here. I downloaded the sleep.c module:
/**
* @file moderAVR_sleep.c
* @author askn (K.Sato) multix.jp
* @brief
* @version 0.1
* @date 2023-10-23
*
* @copyright Copyright (c) 2023
*
*/
/* Note: Does not work with tinyAVR-0/1 and megaAVR-0 */
/* Please run on tinyAVR-2 and AVR_Dx/Ex */
/* Build with only AVR-LIBC header files */
#include <avr/io.h>
#include <avr/sleep.h>
#include <util/atomic.h>
int main (void) {
/*
* Set F_CPU to 512Hz
*/
#if defined(CLKCTRL_TIMEBASE_gm)
/* This CLKCTRL_TIMEBASE_gm symbol is currently only in AVR_EA/EB */
#define EVSYS_CHANNEL0_CCL_LUT0_gc EVSYS_CHANNEL_CCL_LUT0_gc
#define CLKSEL_OSC32K_gc CLKCTRL_CLKSEL_OSC32K_gc
#define CLKCTRL_PDIV_64X_gc CLKCTRL_PDIV_DIV64_gc
#elif (LOCKBITS_SIZE == 1)
/* Symbol alias for tinyAVR-2 */
#define CLKSEL_OSC32K_gc CLKCTRL_CLKSEL_XOSC32K_gc
#endif
_PROTECTED_WRITE(CLKCTRL_MCLKCTRLA, CLKSEL_OSC32K_gc);
_PROTECTED_WRITE(CLKCTRL_MCLKCTRLB, CLKCTRL_PDIV_64X_gc | CLKCTRL_PEN_bm);
/*
* Capture PWM WOB0 output with LUT0 input
*/
CCL_TRUTH0 = CCL_TRUTH_1_bm;
CCL_LUT0CTRLB = CCL_INSEL0_TCB0_gc; // <-- in WOB0
CCL_LUT0CTRLA = CCL_ENABLE_bm; // --> out LUT0_OUT
CCL_CTRLA = CCL_ENABLE_bm;
/*
* Copy LUT0_OUT output to EVOUTA_ALT1 input
* Connect the LED to PA7
*/
PORTMUX_EVSYSROUTEA = PORTMUX_EVOUTA_ALT1_gc; // --> in EVOUTA_ALT1 (PA7)
EVSYS_CHANNEL0 = EVSYS_CHANNEL0_CCL_LUT0_gc; // <-- out LUT0_OUT
EVSYS_USEREVSYSEVOUTA = EVSYS_USER_CHANNEL0_gc; // Binding
/*
* Set the PWM (WOB0) output period to 1Hz
*/
TCB0_CCMP = ((127) << 8) | 255; // PWM duty cycle 50:50
TCB0_CTRLB = TCB_CNTMODE_PWM8_gc; // --> out WOB0
TCB0_CTRLA = TCB_ENABLE_bm | TCB_RUNSTDBY_bm | // Runs TCB0 even if the CPU is STANDBY
TCB_CLKSEL_DIV2_gc; // Runs TCB0 counter on 1/2 of F_CPU
/*
* Sleeps the CPU in STANDBY mode
*/
set_sleep_mode(SLEEP_MODE_STANDBY);
sleep_enable();
sleep_cpu();
/* Since there are no interrupts, this will never be executed again. */
}
// end of codeas well as the makefile:
DEVICE=avr128db64
CFLAGS ?= -Os -DF_APU=512UL -mmcu=${DEVICE} -I/usr/local/avr/include
LDFLAGS ?= -mmcu=${DEVICE} -L/usr/local/avr/lib/avrxmega4
all: sleep.hex
sleep.hex: sleep.elf
avr-objcopy -O ihex sleep.elf sleep.hex
sleep.elf: sleep.o
avr-gcc $(LDFLAGS) -o $@ $^
sleep.o: sleep.c
avr-gcc $(CFLAGS) -c -o $@ $<
clean: FRC
rm -f sleep.elf sleep.hex sleep.o
FRC:Since I'm using Fedora 38 for development, I had to build avr-libc from sources. The one that is provided in fedora packages is 2.0, which doesn't support Dx devices.
I have also downloaded the latest avr-libc from here https://github.com/avrdudes/avr-libc/tree/main and built it according to instructions in the INSTALL file.
Now, when I try to build the hex file I get:
make clean all
rm -f sleep.elf sleep.hex sleep.o
avr-gcc -Os -DF_APU=512UL -mmcu=avr128db64 -I/usr/local/avr/include -c -o sleep.o sleep.c
In file included from /usr/local/avr/include/avr/io.h:759,
from sleep.c:16:
/usr/local/avr/include/avr/lock.h:234: warning: "LOCKBITS_DEFAULT" redefined
234 | #define LOCKBITS_DEFAULT (0xFF)
|
In file included from /usr/local/avr/include/avr/io.h:709:
/usr/local/avr/include/avr/ioavr128db64.h:8273: note: this is the location of the previous definition
8273 | #define LOCKBITS_DEFAULT (0x5CC5C55C)
|
avr-gcc -mmcu=avr128db64 -L/usr/local/avr/lib/avrxmega4 -o sleep.elf sleep.o
/usr/lib/gcc/avr/13.2.0/../../../../avr/bin/ld: cannot find crtavr128db64.o: No such file or directory
collect2: error: ld returned 1 exit status
make: *** [makefile:11: sleep.elf] Error 1This is weird, because:
ls -l /usr/local/avr/lib/avrxmega4/crtavr128db64.o
-rw-r--r--. 1 root root 69132 Oct 26 08:37 /usr/local/avr/lib/avrxmega4/crtavr128db64.oWhat also surprises me is that with avr-libc build from sources I have to provide this weird linker path: -L/usr/local/avr/lib/avrxmega4
I tried also building on MacOS, running into completely different set of issues there.
And the worst part is that I have had it working just fine, the whole toolchain, and now it seems I have two computers where I can't build a single hex file and very little motivation to actually keep going with it...
mcuee
commented
1 year ago @dbuchwald
FYI I use the prebuild toolchain from @SpenceKonde. You can give it a try. https://spencekondetoolchains.s3.amazonaws.com/
For Windows I use the one mentioned in DxCore README. https://github.com/SpenceKonde/DxCore/blob/master/megaavr/bootloaders/optiboot_dx/README.md https://spencekondetoolchains.s3.amazonaws.com/avr-gcc-7.3.0-atmel3.6.1-azduino6-i686-w64-mingw32.tar.bz2
For Linux, you can use the following. https://spencekondetoolchains.s3.amazonaws.com/avr-gcc-7.3.0-atmel3.6.1-azduino6-x86_64-pc-linux-gnu.tar.bz2
For macOS, you can use the following. https://spencekondetoolchains.s3.amazonaws.com/avr-gcc-7.3.0-atmel3.6.1-azduino6-x86_64-apple-darwin14.tar.bz2
I think he has built some new versions which you can also try.
mcuee
commented
1 year ago @dbuchwald
If you want to build your own toolchain, you can also use the one from Microchip as the base. https://www.microchip.com/en-us/tools-resources/develop/microchip-studio/gcc-compilers
And then you need to download the relevant DFP packs from Microchip. https://packs.download.microchip.com/
dbuchwald
commented
1 year ago @mcuee Thanks a lot, with your suggestion I managed to solve the issue on both of my machines now!
dbuchwald
commented
1 year ago @askn37
Hello, I tried replicating the sleep issue, but I think I might be doing something wrong. I built the sleep.c file for my Curiosity Nano AVR128DA48 board, uploaded it using the onboard programmer (pkobn_updi), and then tried contacting the device using serialupdi programmer - and it seems to be responding fine, it just reports that the device was in SLEEP mode, but works as if everything was OK.
What am I doing wrong here?
avrdude -c pkobn_updi -p avr128da48 -U flash:w:sleep.hex
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9708 (probably avr128da48)
avrdude: Note: flash memory has been specified, an erase cycle will be performed.
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: processing -U flash:w:sleep.hex:i
avrdude: reading input file sleep.hex for flash
with 364 bytes in 1 section within [0, 0x16b]
using 1 page and 148 pad bytes
avrdude: writing 364 bytes flash ...
Writing | ################################################## | 100% 0.25 s
avrdude: 364 bytes of flash written
avrdude: verifying flash memory against sleep.hex
Reading | ################################################## | 100% 0.09 s
avrdude: 364 bytes of flash verified
avrdude done. Thank you.
❯ avrdude -c serialupdi -P /dev/cu.usbserial-1420 -p avr128da48 -v
avrdude: Version 7.2-20231024 (d6c61f5f)
Copyright the AVRDUDE authors;
see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is /usr/local/etc/avrdude.conf
User configuration file is /Users/dawid/.avrduderc
User configuration file does not exist or is not a regular file, skipping
Using Port : /dev/cu.usbserial-1420
Using Programmer : serialupdi
AVR Part : AVR128DA48
RESET disposition : dedicated
RETRY pulse : SCK
Serial program mode : yes
Parallel program mode : yes
Memory Detail :
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
fuse0 wdtcfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse1 bodcfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse2 osccfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse5 syscfg0 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse6 syscfg1 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse7 codesize 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse8 bootsize 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuses 0 0 0 0 no 16 16 0 0 0 0x00 0x00
lock 0 0 0 0 no 4 1 0 0 0 0x00 0x00
prodsig sigrow 0 0 0 0 no 128 128 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 1 0 0 0 0x00 0x00
tempsense 0 0 0 0 no 4 1 0 0 0 0x00 0x00
sernum 0 0 0 0 no 16 1 0 0 0 0x00 0x00
userrow usersig 0 0 0 0 no 32 32 0 0 0 0x00 0x00
data 0 0 0 0 no 0 1 0 0 0 0x00 0x00
io 0 0 0 0 no 4160 1 0 0 0 0x00 0x00
sib 0 0 0 0 no 32 1 0 0 0 0x00 0x00
eeprom 0 0 0 0 no 512 1 0 0 0 0x00 0x00
flash 0 0 0 0 no 131072 512 0 0 0 0x00 0x00
Programmer Type : serialupdi
Description : SerialUPDI
avrdude: device is in SLEEP mode
avrdude: NVM type 2: 24-bit, word oriented write
avrdude: Chip silicon revision: 1.6
avrdude: entering NVM programming mode
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9708 (probably avr128da48)
avrdude: leaving NVM programming mode
avrdude done. Thank you.@dbuchwald
Interestingly I also can not reproduce the issue under Linux for the AVR64DD32 board (which I have issues under Windows). There are no issues with -v or -vvvv.
mcuee@UbuntuSwift3 ~/build/avr/avrdude_bin $ make
avr-gcc -Os -DF_APU=512UL -mmcu=avr64dd32 -c -o sleep.o sleep.c
avr-gcc -mmcu=avr64dd32 -o sleep.elf sleep.o
avr-objcopy -O ihex sleep.elf sleep.hex
mcuee@UbuntuSwift3 ~/build/avr/avrdude_bin $ ./avrdude_git -c serialupdi -P /dev/ttyUSB0 -p avr64dd32 -U sleep.hex
avrdude_git: AVR device initialized and ready to accept instructions
avrdude_git: device signature = 0x1e961a (probably avr64dd32)
avrdude_git: Note: flash memory has been specified, an erase cycle will be performed.
To disable this feature, specify the -D option.
avrdude_git: erasing chip
avrdude_git: processing -U flash:w:sleep.hex:i
avrdude_git: reading input file sleep.hex for flash
with 276 bytes in 1 section within [0, 0x113]
using 1 page and 236 pad bytes
avrdude_git: writing 276 bytes flash ...
Writing | ################################################## | 100% 0.17 s
avrdude_git: 276 bytes of flash written
avrdude_git: verifying flash memory against sleep.hex
Reading | ################################################## | 100% 0.07 s
avrdude_git: 276 bytes of flash verified
avrdude_git done. Thank you.
mcuee@UbuntuSwift3 ~/build/avr/avrdude_bin $ ./avrdude_git -c serialupdi -P /dev/ttyUSB0 -p avr64dd32 -v
avrdude_git: Version 7.2-20231024 (d6c61f5f)
Copyright the AVRDUDE authors;
see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is /home/mcuee/build/avr/avrdude_bin/avrdude.conf
User configuration file is /home/mcuee/.avrduderc
User configuration file does not exist or is not a regular file, skipping
Using Port : /dev/ttyUSB0
Using Programmer : serialupdi
AVR Part : AVR64DD32
RESET disposition : dedicated
RETRY pulse : SCK
Serial program mode : yes
Parallel program mode : yes
Memory Detail :
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
fuse0 wdtcfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse1 bodcfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse2 osccfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse5 syscfg0 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse6 syscfg1 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse7 codesize 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse8 bootsize 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuses 0 0 0 0 no 16 16 0 0 0 0x00 0x00
lock 0 0 0 0 no 4 1 0 0 0 0x00 0x00
prodsig sigrow 0 0 0 0 no 128 128 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 1 0 0 0 0x00 0x00
tempsense 0 0 0 0 no 4 1 0 0 0 0x00 0x00
sernum 0 0 0 0 no 16 1 0 0 0 0x00 0x00
userrow usersig 0 0 0 0 no 32 32 0 0 0 0x00 0x00
data 0 0 0 0 no 0 1 0 0 0 0x00 0x00
io 0 0 0 0 no 4160 1 0 0 0 0x00 0x00
sib 0 0 0 0 no 32 1 0 0 0 0x00 0x00
eeprom 0 0 0 0 no 256 1 0 0 0 0x00 0x00
flash 0 0 0 0 no 65536 512 0 0 0 0x00 0x00
Programmer Type : serialupdi
Description : SerialUPDI
avrdude_git: device is in SLEEP mode
avrdude_git: NVM type 2: 24-bit, word oriented write
avrdude_git: Chip silicon revision: 1.3
avrdude_git: entering NVM programming mode
avrdude_git: AVR device initialized and ready to accept instructions
avrdude_git: device signature = 0x1e961a (probably avr64dd32)
avrdude_git: leaving NVM programming mode
avrdude_git done. Thank you.I can not reproduce the issue under my Mac Mini M1 either. I am running the latest macOS Sonoma.
mcuee
commented
1 year ago So it may seems to be a timing issue under Windows, at least for my side.
@askn37 Please give the latest git main a try to see if you can reproduce the Sleep issue or not under macOS. Thanks.
From your run log.
+ ./avrdude/build_darwin/src/avrdude -xrtsdtr=high -p avr64ea32 -c serialupdi -P /dev/cu.usbserial-1320 -U flash:r:avr128db32/Flash.hex:i -v
+ tee log/test_sleep.log
avrdude: Version 7.2-20231018 (481a91dd)
Copyright the AVRDUDE authors;
see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is /Users/askn/Arduino/UPDI_TEST/avrdude/build_darwin/src/avrdude.conf
User configuration file is /Users/askn/.avrduderc
Using Port : /dev/cu.usbserial-1320
Using Programmer : serialupdi
avrdude: opening serial port ...
avrdude: sending 1 bytes [0x00]
avrdude: send: . [00]
avrdude: recv: . [00]
AVR Part : AVR64EA32
RESET disposition : dedicated
RETRY pulse : SCK
Serial program mode : yes
Parallel program mode : yes
Memory Detail :
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
fuse0 wdtcfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
fuse1 bodcfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
fuse2 osccfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
fuse5 syscfg0 0 0 0 0 no 1 1 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
fuse6 syscfg1 0 0 0 0 no 1 1 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
fuse7 codesize 0 0 0 0 no 1 1 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
fuse8 bootsize 0 0 0 0 no 1 1 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
fuses 0 0 0 0 no 16 16 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
lock 0 0 0 0 no 4 1 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
prodsig sigrow 0 0 0 0 no 128 128 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
signature 0 0 0 0 no 3 1 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
tempsense 0 0 0 0 no 4 1 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
sernum 0 0 0 0 no 16 1 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
userrow usersig 0 0 0 0 no 64 64 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
data 0 0 0 0 no 0 1 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
io 0 0 0 0 no 4160 1 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
sib 0 0 0 0 no 32 1 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 0 0 0 0 no 512 8 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
flash 0 0 0 0 no 65536 128 0 0 0 0x00 0x00
Programmer Type : serialupdi
Description : SerialUPDI
avrdude: STCS 0x08 to address 0x03
avrdude: sending 3 bytes [0x55, 0xc3, 0x08]
avrdude: send: U [55] . [c3] . [08]
avrdude: recv: U [55] . [c3] . [08]
avrdude: STCS 0x80 to address 0x02
avrdude: sending 3 bytes [0x55, 0xc2, 0x80]
avrdude: send: U [55] . [c2] . [80]
avrdude: recv: U [55] . [c2] . [80]
avrdude: LDCS from 0x00
avrdude: sending 2 bytes [0x55, 0x80]
avrdude: send: U [55] . [80]
avrdude: recv: U [55] . [80]
avrdude: recv: 0 [30]
avrdude: received 1 bytes [0x30]
avrdude: UDPI init OK
avrdude: UPDI link initialization OK
avrdude: forcing serial DTR/RTS handshake lines HIGH
avrdude: LDCS from 0x0B
avrdude: sending 2 bytes [0x55, 0x8b]
avrdude: send: U [55] . [8b]
avrdude: recv: U [55] . [8b]
avrdude: recv: . [00]
avrdude: received 1 bytes [0x00]
avrdude: sending 2 bytes [0x55, 0xe6]
avrdude: send: U [55] . [e6]
avrdude: recv: U [55] . [e6]
avrdude: recv: A [41] V [56] R [52] [20] [20] [20] [20] [20] P [50] : [3a] 3 [33] D [44] : [3a] 1 [31] - [2d] 3 [33] M [4d] 2 [32] [20] ( [28] B [42] 1 [31] . [2e] 5 [35] 9 [39] F [46] 0 [30] 2 [32] . [2e] 0 [30] ) [29] . [00]
avrdude: received 32 bytes [0x41, 0x56, 0x52, 0x20, 0x20, 0x20, 0x20, 0x20, 0x50, 0x3a, 0x33, 0x44, 0x3a, 0x31, 0x2d, 0x33, 0x4d, 0x32, 0x20, 0x28, 0x42, 0x31, 0x2e, 0x35, 0x39, 0x46, 0x30, 0x32, 0x2e, 0x30, 0x29, 0x00]
avrdude: received SIB: [AVR P:3D:1-3M2 (B1.59F02.0)]
avrdude: Device family ID: AVR
avrdude: NVM interface: P:3
avrdude: Debug interface: D:1
avrdude: PDI oscillator: 3M2
avrdude: Extra information: (B1.59F02.0)
avrdude: NVM type 3: 16-bit, page oriented
avrdude: reading 1 bytes from 0x000F01
avrdude: ST_PTR to 0x000F01
avrdude: sending 4 bytes [0x55, 0x69, 0x01, 0x0f]
avrdude: send: U [55] i [69] . [01] . [0f]
avrdude: recv: U [55] i [69] . [01] . [0f]
avrdude: ser_recv(): programmer is not responding
avrdude: serialupdi_recv(): programmer is not responding
avrdude: UPDI ST_PTR recv failed on ACK
avrdude: ST_PTR operation failed
avrdude serialupdi_initialize() [serialupdi.c:636] error: Reading chip silicon revision failed
avrdude main() [main.c:1404] error: initialization failed, rc=-1
- double check the connections and try again
- use -b to set lower baud rate, e.g. -b 57600
- use -F to override this check
avrdude: leaving NVM programming mode
avrdude: sending reset request
avrdude: STCS 0x59 to address 0x08
avrdude: sending 3 bytes [0x55, 0xc8, 0x59]
avrdude: send: U [55] . [c8] Y [59]
avrdude: recv: U [55] . [c8] Y [59]
avrdude: sending release reset request
avrdude: STCS 0x00 to address 0x08
avrdude: sending 3 bytes [0x55, 0xc8, 0x00]
avrdude: send: U [55] . [c8] . [00]
avrdude: recv: U [55] . [c8] . [00]
avrdude: STCS 0x0C to address 0x03
avrdude: sending 3 bytes [0x55, 0xc3, 0x0c]
avrdude: send: U [55] . [c3] . [0c]
avrdude: recv: U [55] . [c3] . [0c]
avrdude: releasing DTR/RTS handshake lines
avrdude done. Thank you.
Report: Incorrect SerialUPDI control of AVR64EA32
This is a known bug as of commit 481a91d.
case.1 Debug log
case.2 Debug log
Need additional information?
I design my own program writer and create firmware that meets various practical needs. This time, we also acquired control including HV programming using AVR64EA32. I noticed this problem when I was doing comparison testing with other programmers.
NVMCTRL version 3 can correctly interpret 24-bit extended addresses. Although this is clearly stated in the datasheet, NVMCTRL_ADDRESS is a 24-bit register. This allows 16-bit address commands for UPDI access to correspond to LD/ST instructions, and 24-bit address commands to correspond to ELPM/SPM instructions. To treat the flash memory area linearly, you need to set his MSB of this address. In other words, the setting value is 0x800000 or higher. This behavior is equivalent to the AVR_Dx series (NVMCTRL version 2).
This series has a maximum flash capacity of 64KiB, so there is no RAMPZ register. The FLMAP field, which switches the latter bank of data space, also uses only one bit. However, there is no need to manipulate these from UPDI.
REVID register 0xF01 is a register in the IO memory space, so it can only be read when the CPU is active or in his NVMPROG mode. The current implementation of SerialUPDI probably does not take into account the existence of power-saving devices that regularly use CPU sleep.
(Supplement) Use PF6 (RESET pad) to enable high voltage mode. The datasheet states the absolute rating is 9V. Therefore, a suitable high voltage here is 8.2 V when using a Zener diode. However, PICkit4 can exceed this voltage and violate ESD protection.
Further additional information
There are two execution result logs here. Both are displayed when -vvvvq is specified. One result is the target device is asleep, and the other result is the target device is running.
test_run.log test_sleep.log