-
Notifications
You must be signed in to change notification settings - Fork 136
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bootrow r/w does not work for -c serialupdi
#1832
Comments
Sorry for the delay in reply, I hope to find some time tomorrow to look into it. I took a quick look at the code now and the message you get in the trace:
means basically that the bootrow memory is not recognized by
to:
build and try again. This change is based on the following note from preliminary datasheet which suggests to treat bootrow memory as a regular flash: EDIT: Actually nevermind, please pick up version from the following PR: It does make the bootrow update work. There is one strange thing though, and I need to look into it further. Basically - the operations works, but just once. If you want to perform another bootrow update, it will fail, and the data written to (and read back from) bootrow will be invalid. There is a way to work around it, by simply adding That being said, I will look into it, but I can't promise it can even be solved. I have seen similar issues in the past - correct data is sent to the device, but strange data is read back from it. What I did find in the documentation is that when flash memory is to be updated, chip erase is performed by default. Maybe the same approach should be used when writing to bootrow? |
@dbuchwald You have nailed it. Thank you. With your fix now all memories of the new AVR-EB can be read/written including bootrow. Brilliant. Please create a PR in your own time (no rush!) so you get the credit for adapting serialupdi to new chips. Create random multi-memory file for AVR16EB28
Write that file to, and verify it against, a real AVR16EB28 using serialupdi (incl bootrow)
|
Please note: double write to bootrow fails, I need to look into it some more. Will let you know soon. |
Temrinal works, I guess, b/c the code checks whether a failed write is consistent with NOR-memory writes (cannot set 1's) so the terminal utilises page erase |
OK, I will probably need some guidance here. There are basically two ways to go about it - solve the problem on memory definition level or on NVM programmer level, and here is the description/comparison of the approaches: Memory definition level
It's controlled by the
So, changing Advantages:
Disadvantages:
NVM Programmer Level
I tested it and it works nicely on my NVM v5 16eb28 chip. The problem is that this approach doesn't address any of NVM v2/v4 devices (and quite honestly I don't know whether I should bother - are there any NVM v2/v4 devices with bootrow?), and is quite specific. This might be an issue down the line with new NVM revisions. Advantages:
Disadvantages:
Sorry, I just don't want to make this kind of decision on my own, it seems to go way beyond technical implementation of SerialUPDI programmer. Any feedback would be really appreciated. |
Since I wanted to take advantage of some spare time, I created PR for the second approach - implementing separate methods for bootrow handling that will ensure memory erasure prior to write. It either happens using explicit page erase prior to page write or using page erase/page write command on compatible NVM controllers. It would be awesome, though, if it could be tested against any of the v4 devices - I don't have one to check it... You can now choose which PR you would like to merge @stefanrueger :) |
Thanks, @dbuchwald for in-depth analysis. There may be a third way to go about this: diff --git a/src/main.c b/src/main.c
index 3e15575f..050ac815 100644
--- a/src/main.c
+++ b/src/main.c
@@ -1681,8 +1681,8 @@ skipopen:
}
if (uflags & UF_AUTO_ERASE) {
- if ((p->prog_modes & PM_PDI) && pgm->page_erase && lsize(updates) > 0) {
- pmsg_info("Note: programmer supports page erase for Xmega devices.\n");
+ if ((p->prog_modes & (PM_PDI | PM_UPDI)) && pgm->page_erase && lsize(updates) > 0) {
+ pmsg_info("Note: programmer supports page erase for Xmega/AVR8X devices.\n");
imsg_info("Each page will be erased before programming it, but no chip erase is performed.\n");
imsg_info("To disable page erases, specify the -D option; for a chip-erase, use the -e option.\n");
} else { This treats UPDI parts like PDI if the programmer implements Traditionally, AVRDUDE tended to separate page erase from paged write. Though, in my book, it is totally fine if a programmer always erases a page before writing it: there is no universal law that states flash memory must look like NOR-memory (meaning bit cannot be set to 1 while programming). BTW I have to dash, but will have a look at the alternative implementation (thank you @dbuchwald), but this might take a few days. @dbuchwald Could you check how above third alternative would work with the serialupdi implememtation? We'd need to also see how this might influence other UPDI programmers. |
Alternative fix proposal for #1832
Accessing bootrow does not seem to work for
-c serialupdi
:Serialupdi self-diagnoses an invalid memory for paged write.
It is also remarkable that AVRDUDE thinks the operation went OK. The reason for this is that
avr.c
uses an ISP-like programming mechanism (load bytes to page buffer then issue an ISP page write command) when the dedicatedpaged_write()
failsavrdude/src/avr.c
Lines 1147 to 1149 in 41781bd
avr.c
deploys the programmer'sserialupdi_write_byte()
function, indirectly called hereavrdude/src/avr.c
Line 1205 in 41781bd
So paged write to bootrow returns a failure; the fallback bytewise write returns OK, but it doesn't look like it was successful:
@dbuchwald I was wondering whether you could solve that riddle? Trace output 16eb28.txt
It's the AVR-DU and AVR-EB parts that have a
bootrow
memory. I also tried the64du28
, which showed the same behaviour.The text was updated successfully, but these errors were encountered: