AVR Downloader/UploaDEr - Bugs: bug #61624, [Feature request] Serial/UART UPDI...
You are not allowed to post comments on this tracker with your current authentication level.
bug #61624: [Feature request] Serial/UART UPDI programmers
Submitter: | None | ||
Submitted: | Mon 06 Dec 2021 11:57:08 AM UTC | ||
Category: | None | Severity: | 3 - Normal |
Priority: | 5 - Normal | Item Group: | None |
Status: | In Progress | Privacy: | Public |
Assigned to: | dawidbuchwald | Originator Name: | Hans |
Originator Email: | -email is unavailable- | Open/Closed: | Open |
Release: | SVN snapshot | Programmer hardware: | serialupdi |
Device type: |
Jump to the original submission
Wed 15 Dec 2021 02:14:18 PM UTC, comment #24: |
Dawid Buchwald <dawidbuchwald>![]() ![]() |
Mon 13 Dec 2021 09:46:37 PM UTC, comment #23:
|
mcudude <mcudude> |
Mon 13 Dec 2021 09:21:29 PM UTC, comment #22:
|
Dawid Buchwald <dawidbuchwald>![]() ![]() |
Mon 13 Dec 2021 08:00:47 PM UTC, comment #21:
|
mcudude <mcudude> |
Mon 13 Dec 2021 07:10:39 PM UTC, comment #20: Hello again! I'm really happy to hear that it works fine with other chips as well. At this point I will focus on some code refactoring and cleanup, because some of the code written today was just a quick and dirty implementation.
|
Dawid Buchwald <dawidbuchwald>![]() ![]() |
Mon 13 Dec 2021 06:57:04 PM UTC, comment #19: Hello again Dawid!
|
mcudude <mcudude> |
Mon 13 Dec 2021 02:30:38 PM UTC, comment #18: I just tested reading from and writing to EEPROM on an ATmega4808 and ATmega4809, and it seems to work just fine. I've loaded various hex files, and the content read from EEPROM is always correct. It's also very fast, reading and writing take about a second, reading a little shorter perhaps.
|
mcudude <mcudude> |
Mon 13 Dec 2021 02:06:30 PM UTC, comment #17: Hey, thanks a lot for your help! I'm happy to hear that it's working now.
|
Dawid Buchwald <dawidbuchwald>![]() ![]() |
Mon 13 Dec 2021 02:00:47 PM UTC, comment #16: Hi! I have now tested your latest version on ATmega4809, 3209, 4808, and 3208, and everything seems to be working fine. All fuses are set and read back correctly, and I'm not getting any segment errors anymore.
|
mcudude <mcudude> |
Mon 13 Dec 2021 11:04:13 AM UTC, comment #15: Hey, I have just posted another fix that should take care of the fuse write. Sorry for all the inconvenience. I would really appreciate if you could check it and let me know if it works correctly now.
|
Dawid Buchwald <dawidbuchwald>![]() ![]() |
Mon 13 Dec 2021 10:29:54 AM UTC, comment #14:
AVR128DB28 fuses. I think I know what this is, working on a fix now, should
|
mcudude <mcudude> |
Mon 13 Dec 2021 10:27:00 AM UTC, comment #13: Yeah, I just checked and the same issue occurs when trying to save to AVR128DB28 fuses. I think I know what this is, working on a fix now, should have it ready in a moment. Will let you know when it's ready. |
Dawid Buchwald <dawidbuchwald>![]() ![]() |
Mon 13 Dec 2021 10:23:17 AM UTC, comment #12: I can confirm that the uploaded program works as expected.
|
mcudude <mcudude> |
Mon 13 Dec 2021 10:01:35 AM UTC, comment #11: Hey, I'm glad to hear that at least flash programming works correctly now. I assume that once uploaded, programs work as expected? Could you confirm this?
|
Dawid Buchwald <dawidbuchwald>![]() ![]() |
Mon 13 Dec 2021 09:29:23 AM UTC, comment #10: Thanks Dawid, reading from flash now works in the ATmega4809!
|
mcudude <mcudude> |
Mon 13 Dec 2021 08:52:58 AM UTC, comment #9: Thanks a lot for your support, I really appreciate the time and effort. I think I have a fix for you. What you have to do is:
|
Dawid Buchwald <dawidbuchwald>![]() ![]() |
Mon 13 Dec 2021 08:33:50 AM UTC, comment #8:
work for you. Unfortunately, I don't own any other UPDI based MCUs, and there
|
mcudude <mcudude> |
Mon 13 Dec 2021 08:29:25 AM UTC, comment #7: First of all, thank you A LOT for your time and I'm really sorry it didn't work for you. Unfortunately, I don't own any other UPDI based MCUs, and there are apparently three different programming models for those, so I need to do some shopping today.
|
Dawid Buchwald <dawidbuchwald>![]() ![]() |
Sun 12 Dec 2021 11:04:03 PM UTC, comment #6: No worries! I was able to build after following your instructions. It would be really nice if the DTR/RTS pulse could stay low during the entire Avrdude session. At the moment there seem to be two short (250us) pulses, one at the start and one at the end. This is different from how pymcuprog behaves. As mentioned in an earlier post, this signal could be used to control some simple digital logic that could automatically switch between UPDI and UART mode on a programmer.
|
mcudude <mcudude> |
Sun 12 Dec 2021 10:05:17 PM UTC, comment #5: Sorry, should have been clearer. You should do the following:
|
Dawid Buchwald <dawidbuchwald>![]() ![]() |
Sun 12 Dec 2021 09:09:40 PM UTC, comment #4: Hi David!
|
mcudude <mcudude> |
Sun 12 Dec 2021 08:07:29 PM UTC, comment #3: Hello, I have some good news for you - I have first alpha version of the SerialUPDI programmer. I hope you can give it a spin and let me know if it works for you. I'm using FT232RL chip with a diode between Rx and Tx, 1K resistor between Tx and Diode and 470 resistor between UPDI pin and the diode, just like the "ideal" setup described in SerialUPDI documentation.
|
Dawid Buchwald <dawidbuchwald>![]() ![]() |
Mon 06 Dec 2021 02:08:33 PM UTC, comment #2: Sorry for not creating this issue with my actual account. I totally forgot that I had one! Anyways, I'm very excited about this, but also for the fact that there finally is some work done to Avrdude. It is after all an invaluable tool for SO many AVR developers!
|
mcudude <mcudude> |
Mon 06 Dec 2021 12:05:43 PM UTC, comment #1: Dawid already volunteered to do just this. ;-) |
Joerg Wunsch <joerg_wunsch>![]() |
Mon 06 Dec 2021 11:57:08 AM UTC, original submission:
I know this is a lot to ask, and I don't expect anyone to jump onto this immediately because one guy would find this incredibly useful.
|
Anonymous |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 2 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2021-12-06 | joerg_wunsch | Status | None | ![]() |
In Progress |
Assigned to | None | ![]() |
dawidbuchwald |
Let me start with reply, followed by status update.
I suppose this is because they are in process of finalising the design? I have no idea, but I would rather expect even more versions in future. This, unfortunately, means that further changes to the UPDI code will be required at some point.
After some more investigation I concluded that there are actually different scenarios where Safemode is disabled, so I would really leave that for now.
Not that short update
So I managed to implement lockbits handling, turned out pretty easy to do. It works, I spent few hours scratching my head and trying to figure out how to unlock the device.
I have also tested potential change to avrdude.conf, related to AVR Dx family EEPROM page size - it works nicely with my programmer and size 0x20, but I'm a bit afraid it might not work with other programmers, so I won't change that. The only reason to play with this value is the efficiency of EEPROM write - it takes over a minute with 1-byte pages (there's huge overhead on UPDI communication) compared to ten seconds in 32-byte page mode.
Thing is - safety first. I don't write to EEPROM outside of my tests, so maybe better to leave it be.
So yeah, all the memories listed in AVRDUDE.CONF can be accessed now. Fuses can be configured, flash and EEPROM written, entire chip locked and unlocked. Error handling has been somewhat improved, AVRDUDE can now recover from crashing.
You can fetch latest version (revision 1522) to play with it, but it's not final, so consider carefully whether it's worth your time.
What I'm planning to do next is to do yet another refactoring. I don't like current model of error handling (inherited from pymcuprog) and I need to look into some weirder scenarios (like: lock the chip and upload flash with forced chip erase - it will work, but only the second time).
I'm also still waiting for all the tinyAVR chips. With the global shortage I had to order them abroad, and it's literally the worst time during the year to do it, so I will probably wait a bit longer. Good thing is I got all the types (0/1/2 as well as the mega ones).