avrdude-slic3r sending garbage blocks to the simulator about mk404

[leptun]

You might need this to upload the secondary language. Alternatively, you can use PrusaSlicer
avrdude-slic3r.zip

[vintagepc]

PS basically has a permanent home being open on my taskbar ;)

[vintagepc]

does that avrdude build let you only do the language flash or does it require the entire flash beforehand?

[leptun]

This avrdude is the identical program included in PrusaSlicer, but it it compiled separately. With it you first upload the firmware using the regular bootloader, then it reboots and on a second run of the program you also upload the language section. That part is done using the second bootloader found in the firmware.

[vintagepc]

This is interesting... for some reason when flashing with the bootloader entire chunks of flash do not get written.

Monitoring the UART input (trapping IRQ_UART_BYTE_IN) shows these same blank regions in the data...

[vintagepc]

this gets weirder... tapping the actual serial comms with socat shows the 0xFF bytes are are actually part of what is sent by avrdude-slicer.

Even more interesting, regular avrdude does not do this and the verification pass completes without issue.

[vintagepc]

This almost looks like a concurrency issue. I logged two flash cycles, one with avrdude-slic3r (left) and one with standard avrdude (right)
It's apparent the pages are both getting out of sync (page numbers diverge) and it seems like somehow when running avrdude-slic3r, it is actually clobbering its own written data by subsequently filling problem pages with junk and writing them again.

[vintagepc]

This almost looks like the slicer variant is writing pages in two chunks. Note the differences in the original page data line up with the 0xFB bytes in the second block.

[vintagepc]

I've found a fix, but I don't understand quite why. So apparently avrdude-slicer will do double programming passes on some blocks of flash memory. (i.e. write the pages a second time).

This fails because the simulator doesn't actually behave like flash memory - in reality, doing this would result in an &= of the value. I have a simavr fix for this that results in the avrdude verification pass.

@leptun does this behaviour ring any bells for you, or do you know whom we might ask for the reasoning behind this?

[vintagepc]

I've pushed the fix up to vintagep/simavr in the worktree_test branch. You will need to check it out and recompile simavr to see an effect.

[leptun]

Maybe avrdude-slic3r tries to insert the Percentage done frame in the middle of the write for some odd reason. Not sure what to say. You could ask @DRracer to ask the right person about this

[vintagepc]

Fair enough.
Though the data I'm looking at is the raw stk500 protocol, it's actually instructing it to write that block to flash memory.