SerialUPDI - unable to write USERROW memory on AVR64DU32 #1655
Comments
|
@MCUdude I have prepared preliminary fix, which should not introduce any regression for previously tested chips: https://github.com/dbuchwald/avrdude/tree/issue_1655 Can you check if it fixes issue on AVR64DU28? Basically the change is that if the USERROW memory is larger than 256 bytes then word-based write operation is performed instead of the previously used byte-based write. I have also tested word-based write of USERROW against AVR16EA28 and it seems to have worked just fine, so maybe some day we could simplify code by changing to word-based write for all the UPDI AVRs, but I wouldn't introduce this so late into release cycle. |
I agree that you are absolutely right. The maximum amount of memory that can be written with one set of repeated commands is 256 words, which is consistent with all known datasheet descriptions. At least I haven't read anything else written. And this is probably the upper limit that can be achieved with his current UPDI system. If a page size of 1024 bytes appears in the future, I think the specifications will probably be expanded or some kind of improvement will be proposed at that time. |
|
I'm away for the weekend, but will be back and can continue testing on Sunday evening. But is the userrow size 64 or 512 bytes? |
Sure, sorry, didn't mean to rush you.
For a minute I was hoping it was 64 bytes but no, after inspecting atpack and |
|
It is stated on page 3 to 4 of the brief note. https://askn37.github.io/documents/AVR-DU-Product-Brief-DS40002328.pdf 
Even in this document, it is unlikely that you are confusing it with bit amount. |
|
The following products have been registered on Mouser and DigiKey. FBP-AVR-DU-ISO26262 It appears to be a development kit to obtain ISO 26262 approval. I had no idea it would be possible to pre-order items like this before the individual chips went on sale. From this, we can infer that an automotive-grade derivative of AVR-DU also exists. This suggests that there may be signatures that differ from the usual products, such as the ATtiny416auto example. |
|
@dbuchwald your suggested fix did the trick! 🚀 |
|
Brilliant! Thanks all round for ironing out this problem and confirming it has done so! |
|
@dbuchwald Could you do the honours and submit a PR, please? |
|
@MCUdude thanks for testing it. I'm really glad it worked! @stefanrueger PR is ready here: #1659 |
MCUdude
changed the title
First reported by @MCUdude in discussion #1473.
This issue is related to SerialUPDI programmer and first ever tested DU chip, and it's pretty easy to replicate:
avrdude log
Root cause of the issue is the fact that so far all the USERROW memories were 64 bytes or smaller, and the implementations so far were based on the sequence of "set pointer; repeat <number_of_bytes>; write byte and increase pointer", which was fine as long as these memories were 256 bytes or less (this is limitation of the
repeatcommand which takes single byte as a parameter.Most probably the fix would be to change the USERROW write operation to "set pointer; repeat <number_of_bytes/2>; write 2-byte word and increase pointer", but this could introduce regression to all the old parts, so this needs to be tested carefully.
It would also be very helpful to have access to the datasheet of the chip in question, it might actually contain some guidelines for handling such a large memory.
@stefanrueger, @mcuee, @askn37 - do you think I should add any additional information here?
The text was updated successfully, but these errors were encountered: