Replies: 17 comments 144 replies
-
Beta Was this translation helpful? Give feedback.
-
|
Preliminary issues linked to Milestone AVRDUDE 7.4 (need to be updated later) |
Beta Was this translation helpful? Give feedback.
-
|
Other things to consider:
From @stefanrueger
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
The repology.org page (https://repology.org/project/avrdude/versions) might also be helpful for that kind of overview. |
Beta Was this translation helpful? Give feedback.
-
|
Nice. This is much better than the following link. |
Beta Was this translation helpful? Give feedback.
-
|
The two sets of operating systems are partially disjunct, though. |
Beta Was this translation helpful? Give feedback.
-
|
With me being new here... is there or what is the (very) rough timeline for 7.4? Is it more like 2024-04 or more like 2025-01? |
Beta Was this translation helpful? Give feedback.
-
|
Great to have you here! And thank you for the work you're putting into the build system. We're very grateful to everyone who wants to contribute to the project, whether it's submitting PR(s) or reporting bug(s). I've been around for about two years, and it's amazing to see how much Avrdude has improved since the v6.3 version. The schedule since the v7.0 release has been between 6 and 8 months, and I think we're sticking to that unless there are no significant changes to the code base. |
Beta Was this translation helpful? Give feedback.
-
|
AVR64DU32/28 Online Document and errata have also been published. Online Dpcument Eratta
Unfortunately, sample orders have not started yet, but I have a feeling it will be possible soon. |
Beta Was this translation helpful? Give feedback.
-
|
I am targeting a new release 8.0 start of July. I am suggesting 8.0 given our major steps towards a libavrdude library with its first working example (Jörg's brilliant GUI example PR #1714 that hopefully will be merged by then) as a showpiece. It would be vvv cool and welcome if @ndim's WIP PRs could be part of that release, and also if @mariusgreuel's self-assigned Windows bugs were to have a solution. |
Beta Was this translation helpful? Give feedback.
-
|
That would be great. I agree with version number 8.0. |
Beta Was this translation helpful? Give feedback.
-
|
Since we are approaching a v8.0 release and we are "allowed" to introduce breaking changes, maybe it's a good idea to discuss is there are any annoying things or obsolete features that can be removed? For instance, the |
Beta Was this translation helpful? Give feedback.
-
|
Yes, great idea. I secretly hope to develop a new feature for which I'd prefer to have I sense there is going to be a slip in release date. If the multi-memory files and -U memlist:x:... happens it will need a great deal of testing time as that feature necessitates a rewrite of the core of |
Beta Was this translation helpful? Give feedback.
-
That fits me better, indeed. I'll be off for the first two weeks in July. |
Beta Was this translation helpful? Give feedback.
-
|
Since we're planning an Avrdude v8.0 in in August, we should probably start testing. This is a time consuming task, but our fantastic test script makes this job much easier. @stefanrueger are you planning to do any changes to the script ( And should we do anything about this, now that a new major release are on its way?
|
Beta Was this translation helpful? Give feedback.
-
|
@MCUdude Thanks for getting the ball rolling: the test-avrdude script checked an impressive list of What I am most concerned of for 8.0 are the multi-memory files, memory lists, backup and restore. For me is the real v 8.0 test. We could sandwich the current test script with backup and restore as an alternative, but I think above is currently better and quicker. I'd like to tie up a few PRs first, though I think they won't get in the way of testing. @dl8dtl Do you want to bring your SWIG python wrapper back into the fold, remove it's WIP status and set it free for 8.0? The pickit5 support is getting nicely under way and is neatly separated, so that can slot in after testing the other programmers. |
Beta Was this translation helpful? Give feedback.
-
|
Testing records of avrdude 7.3 release is here. You can see that @MCUdude, @askn37 and I have documented the test results in that discussions. Quite extensive tests were done. |
Beta Was this translation helpful? Give feedback.
-
They were set free for 7.0, then peeps complained, we relented and reserved them again. Either way is fine for me (keeping them reserved for now or freeing them now or freeing them when needed). I'll check for a few other deprecated thingies. |
Beta Was this translation helpful? Give feedback.
-
|
@MCUdude Is it OK to remove the ellipsis forms |
Beta Was this translation helpful? Give feedback.
-
|
Now I remember: the main reason for deprecating those two forms was so it doesn't get mixed up with the fill mode write ellipsis |
Beta Was this translation helpful? Give feedback.
-
|
And can anyone shed light on the message |
Beta Was this translation helpful? Give feedback.
-
|
Well, I really like |
Beta Was this translation helpful? Give feedback.
-
I have never seen a nibobee programmer, but that message has probably been there for a while. If -c nibobee is supported, then -p nibobee could safely be removed. But capital -C? That has to be a mistake. |
Beta Was this translation helpful? Give feedback.
-
Testing results.I'll keep updating this post as I test more parts and programmers. Failing tests done by me should be discussed under this post.
|
Beta Was this translation helpful? Give feedback.
-
|
@stefanrueger so what do we do with the two unused bits? I thought it was best practice to set them to 1. And other programmers I've tested with did not complain about this (IIRC). EDIT: 0x5c comes from the ATDF file. But what is correct? <module caption="Fuses" name="FUSE">
<register-group caption="Fuses" name="FUSE">
<register name="LOW" offset="0x00" size="1" initval="0x5C">
<bitfield caption="Brown-out Detection Level" mask="0x80" name="BODLEVEL" values="ENUM_BODLEVEL"/>
<bitfield caption="Brown-out detection enabled" mask="0x40" name="BODEN"/>
<bitfield caption="Serial program downloading (SPI) enabled" mask="0x20" name="SPIEN"/>
<bitfield caption="External reset function of PB5 disabled" mask="0x10" name="RSTDISBL"/>
<bitfield caption="Clock Select" mask="0x03" name="CKSEL" values="ENUM_SUT_CKSEL"/>
</register> |
Beta Was this translation helpful? Give feedback.
-
Good with USBasp, USBtiny, AVR910 and one FTDI based programmer. Wiring bootloader got issues but it is not a regression and I believe it is a known limitation of the wiring bootloader. Arduino bigboot bootloader from your optiboot-flash repo has issues with ATmega2560 but I think it is again a bootloader limitation. I will continue my testing over this week. Got some time tonight as the original evening meeting got cancelled. |
Beta Was this translation helpful? Give feedback.
-
|
Great, thanks @mcuee! @stefanrueger using an initval of Look at this. The USBasp and the AVRISPmkII reports different fuse bit values from the exact same chip: |
Beta Was this translation helpful? Give feedback.
-
Fuse memories have two parameters: the factory setting For ISP programmers there is the additional layer of how the 4-byte ISP command is assembled. There one can specify In order to understand this be, I am going to push commits onto git main that contain more debug messages for avr_...() I/O functions |
Beta Was this translation helpful? Give feedback.
-
Which would need to be 6 instead. I have pushed a few commits to main to generally improve debugging. Maybe if you post a new log output (no additional -v needed) with the fresh git main, I can figure out who does the complaining (and what to do about it). |
Beta Was this translation helpful? Give feedback.
-
|
Planed testing similar to avrdude 7.3 (but will have less test cases).
Windows 10/11 x64 Test Results Summary MSYS2 mingw64 build (main binaries to test) Last updated on 2024-08-22 MSYS2 mingw64 build (main binaries to test)
VS2019/VS2022 build
Linux tests summary: to be updated
macOS tests summary: to be updated
BSD platforms -- sanity check only: to be updated
|
Beta Was this translation helpful? Give feedback.
-
|
@stefanrueger I just pulled the latest git main. Here are the output (fails writing fuse and lock), and I've attached the log a well. |
Beta Was this translation helpful? Give feedback.
-
As of 7.3, page erase was not used, so this could be considered a regression for Nano Every. NVMCTRL in UPDI silicon does not have EEPROM page erase function. Normally you can write 0xFF anytime. You can erase 1/2/4/8 bytes or the whole thing. There is no known JTAG command for this. The cause is EEPROM page erase, so don't use JTAG command for that. EEPROM can always be overwritten with 0xFF from 1 byte to page size. Nano Every, JTAG2UPDI and UPDI4AVR are such types. FW that doesn't allow 0xFF overwrite may have its own trick to erase EEPROM page by overwriting with 0xFF internally. As in 7.3, shouldn't EEPROM page erase be disabled by default and the Or. The correct solution is probably to provide an alias driver like |
Beta Was this translation helpful? Give feedback.
-
|
Linux gpio is good, tested under Raspberry Pi 400. |
Beta Was this translation helpful? Give feedback.
-
|
linuxspi is also good. |
Beta Was this translation helpful? Give feedback.
-
I agree with you. |
Beta Was this translation helpful? Give feedback.
-
|
Just FYI that Microchip actually installed udev rules for its tools if you install MPLAB X. I just installed MPLAB X 6.20 under Ubuntu 24.04 and here are the udev rules. |
Beta Was this translation helpful? Give feedback.
-
|
@ndim |
Beta Was this translation helpful? Give feedback.
-
|
The matching part is very nice to know, but the action part making everything world writable is less than ideal. However, substituting |
Beta Was this translation helpful? Give feedback.
-
|
Microchip's udev rules file names start with |
Beta Was this translation helpful? Give feedback.
-
@MCUdude Can your tests live without driver-specific parameters? Making the test script take |
Beta Was this translation helpful? Give feedback.
-
I tried this. It is running the latest 1.6.762 EDBG firmware. Still facing the same issue. And I'm having the exact same problem when using Avrdude 7.3:
```
$ avrdude -cxplainedpro_jtag -patmega256rfr2 -U{flash,eeprom,signature,{l,e,h}fuse,lock,calibration}:r:-:I
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1ea802 (probably m256rfr2)
avrdude: processing -U flash:r:-:I avrdude: processing -U eeprom:r:-:I avrdude: processing -U signature:r:-:I avrdude: processing -U lfuse:r:-:I avrdude: processing -U efuse:r:-:I avrdude: processing -U hfuse:r:-:I avrdude: processing -U lock:r:-:I avrdude: processing -U calibration:r:-:I avrdude done. Thank you. |
Beta Was this translation helpful? Give feedback.
-
Do |
Beta Was this translation helpful? Give feedback.
-
|
I don't know how to make MPLAB read/write to multiple memories in a row. I don't even know if they have a CLI to interface with the programmers I can use, apart from the open-source pymcuprog. I just connected my Power Debugger (JTAG) to the ATmega256RFR2, and the bug is still there: (Using git main) The strange thing is that I've only seen this issue on the ATega256RFR2. I've tried with the ATmega1284P, and I'm having no issues there. |
Beta Was this translation helpful? Give feedback.
-
|
I tried filling the memories of the ATmega256RFR2 with known data. And now the incorrect signature contains different data. The calibration value has also changed. But the content read from flash, eeprom and usersig is correct. |
Beta Was this translation helpful? Give feedback.
-
|
I may be on to something. Look what happends when I fill the usersig memory with 0x55's: |
Beta Was this translation helpful? Give feedback.
-
|
I have never used the ATmega256RFR2, ATmega128RFR2, or ATmega64RFR2 families, but this thread caught my attention, so I looked at the datasheet. It appears that the programming interface is JTAG type only. If so, it has nothing to do with the ISP type ATmega1284P (ATmega 4 series). I think jtag3.c should help narrow it down to the JTAG-related parts. To access the application and boot flash areas, you need to specify a 256KiB ==18-bit address using the RAMPZ register and use SPM to distinguish it from the data area, so it is a good idea to check the bit mapping definition relationship. If you are experiencing regressions, it is most likely due to an incorrect choice of MEM_TYPE and memory section offset used regardless of whether you are using JTAG/UPDI/PDI/ISP/TPI etc. |
Beta Was this translation helpful? Give feedback.
-
|
Is signature, calibration etc really overwritten or does the programmer/AVRDUDE only think so? That is some sort of cache gone wrong? Cannot be the terminal cache BTW, as this behaviour shows when using only -U |
Beta Was this translation helpful? Give feedback.
-
See issue #1890. I don't think the memories are overwritten. And |
Beta Was this translation helpful? Give feedback.
-
That's not correct. The AVR core of the ATmegaRF is an ATmega1281, with both, JTAG as well as ISP for programming. |
Beta Was this translation helpful? Give feedback.
-
|
Only difference: the ATmega1281 inherited the ATmega128 (which was inherited from ATmega103 ;-) behaviour of not using MISO/MOSI for ISP, instead using PDI/PDO. The ATmegaRF did not replicate this old habit, they use MISO/MOSI for ISP. |
Beta Was this translation helpful? Give feedback.
-
|
Sure, the |
Beta Was this translation helpful? Give feedback.
-
|
@stefanrueger @MCUdude @dl8dtl and @ndim @askn37 I will carry out a bit more sanity tests over the weekend. But it seems to me the current git is in a good shape towards 8.0 release, thanks to the great work especially by @stefanrueger and @MCUdude. Two things.
|
Beta Was this translation helpful? Give feedback.
-
|
I am not so sure about the following two issues though. Not a regression so probably we can deal with them post 8.0 release. |
Beta Was this translation helpful? Give feedback.
-
|
@dl8dtl @MCUdude @mcuee @askn37 @ndim OK, looks like we have run out of road for an August release. The new feature of multi-memory backups and restore has put into sharp focus the haphazard way different programmers deal with all possible memories. Fair enough, some for example, bootrow, weren't even documented a few months ago, so it's unreasonable to expect AVRDUDE to coax older programmers to deal with all that at the drop of a hat. Git main AVRDUDE has ironed out a lot of that for jtag3 (and more: apptable/boot would never have worked in the past; we found what I now believe to be a silicon bug in the m256rfr2) but has not made a sufficient headway into jtagmkII. There has been an incredible effort to test combinations, but it turns out more is needed and more code analysis is needed. For example, I know that jtagmkII.c is bound to be as problematic as jtag3.c and needs the same kind of work. So, what can be improved? @MCUdude's testing setup is very, very good. I really like the summary tables with the warning triangles and the crosses showing spots that need more work. This is crisp and a great overview. But then, we as a group often would start treads with long avrdude dumps in different places that are hard to scroll, harder to read. From a certain length Git hides posts and replies, so we are even unable to find discussions with search on the page. We will need a bit more use of the details tag, collapsing the long lists, provide -vvv logs, and keep focusing on one problem at a time. I am unavailable for a couple of months. So that will need to continue later in the year, perhaps in Nov, or if that fails maybe in early 2025. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, jtag2 could also need some attention. However, I only have two jtag2 based programmers. One glitchy dragon (probably a HW issue), and one that works. However, it still has random hiccups, where Avrdude complains that the operation. I'm sure it's not the hardwares fault, but either Avrdude or the Dragon FW. But jtag2 programmers are a dying breed, so even though we should iron out known jtag2 issues, I think we should release 8.0 soon and focus on fixing these jtag2 issues in 8.1. Git main has ironed out a lot of bugs we didn't even know 7.3 had! |
Beta Was this translation helpful? Give feedback.
-
|
I am okay with releasing avrdude 8.0 soon, or even just realese the current git main (plus minor routine stuff for a new release, like version number changes) as avrdude 8.0. Arduino Nano Every is in reality not a successful product any way. |
Beta Was this translation helpful? Give feedback.
-
|
Looks like we have hit the buffers with testing. I have merged #1824, #1888, #1910 and #1911 into git main. LMK whether or not you want that as 8.0... |
Beta Was this translation helpful? Give feedback.
-
|
Im currently away, so I'm not able to do any testing until Monday. But if you have anything special you want me to test, please let me know. And @stefanrueger, what du you think about a new release in the near future? |
Beta Was this translation helpful? Give feedback.
-
avrdude 7.3 release is more or less done and it will be released soon (say next week).
Let's start the discussion on the next release avrdude 7.4.
Beta Was this translation helpful? Give feedback.
All reactions