FLASH write fails if there are odd number of bytes.

[InspectorColombo]

Hi!

AVRDUDE fails with writing to FLASH if there are even number of bytes. If bytes count is odd, everything is fine.
I suppose it skips writing for single byte, because AVR commands are always 2(or sometimes, 4) bytes length.
System - Win10_x64
MCU - ATmega8535
Programmer - PonyProg like with COM(RS232) interface.

Actually 1st time I faced this bug in old 2007, with LPT based programmer. I've workaround it by manual add one 0xFF byte to binary file. So, I am surprized, when I saw same problem in 2022. It's weird, that no one reported it before.
Issue is reproduced with bin and with hex file format. And I'm sure it is not programmer or MCU dependent.

TestFiles.zip

Here is test hex and bin files in archive.

r. Peter Falc.

[dl8dtl]

The AVR flash is organized in units of 16 bits. So you cannot write a single 8-bit entity to it.

Strange enough, the LPM instruction can read single bytes out of it anyway. (The SPM instruction can only write 16-bit words.)

Normally, any program that produces flash data for the AVR is supposed to pad them to a full 16-bit word.

[InspectorColombo]

@dl8dtl I know, that it is impossible to write one byte to AVR, because ISP commands are two bytes oriented. But if You write program where You use const string located in PROGMEM(FLASH), there is possible that hex or bin contains odd number of bytes. And Avrdude behave not clear, people thinks that MCU is corrupted, and try to switch it to "good" one.
As I see a solution:

1. Throw an exception like "don't support odd number of bytes in bin/hex file".
   or
2. Write 0xFF as second byte, if only first is defined.

[mcuee]

Write 0xFF as second byte, if only first is defined.

I think this is a good workaround for flash.

[mcuee]

For terminal mode, I think this seems to be okay now (fixed in git main) thanks to @stefanrueger's various fixes to the terminal mode.

$ ./avrdude -qqp m328p -c usbasp -t

avrdude> dump flash 0x1000 0x10
>>> dump flash 0x1000 0x10
1000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

avrdude> write flash 0x1000 "Hello world!\n"
>>> write flash 0x1000 "Hello world!\n"
avrdude> flush
>>> flush
avrdude.exe: synching cache to device... reading/chip erase/writing cycle needed ... done

avrdude> dump flash 0x1000 0x10
>>> dump flash 0x1000 0x10
1000  48 65 6c 6c 6f 20 77 6f  72 6c 64 21 0a 00 ff ff  |Hello world! ...|

avrdude> write flash 0x1000 0xaa
>>> write flash 0x1000 0xaa
avrdude> flush
>>> flush
avrdude.exe: synching cache to device... reading/chip erase/writing cycle needed ... done

avrdude> dump flash 0x1000 0x10
>>> dump flash 0x1000 0x10
1000  aa 65 6c 6c 6f 20 77 6f  72 6c 64 21 0a 00 ff ff  |.ello world! ...|

avrdude> quit
>>> quit

[mcuee]

Actually I can not reproduce the issue for -U as well.

$ srec_cat -generate 0x0000 0x001F -repeat_data 0x00 -o zeros_31bytes.hex -Intel -obs=16

$ ./avrdude -qqp m328p -c usbasp -U zeros_31bytes.hex && echo OK
OK

$ echo dump flash 0 0x20 | ./avrdude -qqp m328p -c usbasp -t
avrdude> >>> dump flash 0 0x20
0000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 ff  |................|

avrdude>

$ srec_cat -generate 0x0000 0x000F -repeat_data 0x55 -o hex55s_15bytes.hex -Intel -obs=16

$ ./avrdude -qqp m328p -c usbasp -U hex55s_15bytes.hex && echo OK
OK

$ echo dump flash 0 0x20 | ./avrdude -qqp m328p -c usbasp -t
avrdude> >>> dump flash 0 0x20
0000  55 55 55 55 55 55 55 55  55 55 55 55 55 55 55 ff  |UUUUUUUUUUUUUUU.|
0010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

avrdude>

[mcuee]

Using the test file from the original report, both avrdude 7.0 release and git main are okay.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude7 -C .\avrdude7.conf -c usbasp -qqp m328p 
-U .\Test_8535.hex && echo OK
OK

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_git -c usbasp -qqp m328p -U .\Test_8535.hex && echo OK
OK

[mcuee]

@InspectorColombo

Can you try different programmers (eg: usbasp) to see if the issue is also there? Thanks.

[InspectorColombo]

Can you try different programmers (eg: usbasp) to see if the issue is also there? Thanks.

Hi, @mcuee !
Right now I built and test latest trunk version of Avrdude.
So, Problem is reproduced only with PonyProg like(Com port based) programmer.
Also, I have self-made USBASP and USBTiny, and there is no error.

With COM port based PonyProg I have this:

Reading | ################################################## | 100% 0.00s

avrdude: device signature = 0x1e9308 (probably m8535)
avrdude: Note: flash memory has been specified, an erase cycle will be performed.
         To disable this feature, specify the -D option.
erasing chip
avrdude: reading input file odd.bin for flash
         with 1893 bytes in 1 section within [0, 0x764]
         using 30 pages and 27 pad bytes
avrdude: writing 1893 bytes flash ...

Writing | ################################################## | 100% 1.19s

avrdude: 1893 bytes of flash written
avrdude: verifying flash memory against odd.bin

Reading | ################################################## | 100% 1.03s

avrdude error: verification mismatch, first encountered at addr 0x0764
        device 0xff != input 0x5a
avrdude error: verification mismatch

avrdude done.  Thank you.

I think reason is - USBASP and USBTINY forms write/read commands inside programmer MCU. But PonyProg do this by avrdude, pulling or pushing COM port pins. So, problem is with PonyProg code.

r. InspectorColombo.

[mcuee]

@InspectorColombo

Would you please try latest git main to see if there are any different in behavior now? Thanks.

I am thinking PR #1188 might help in your situation.

@stefanrueger
Do you think that PR #1188 can help in this case?

[stefanrueger]

I am hoping that PR #1188 removed this issue as -c programmers only ever see full pages to write that would have been padded from device contents. Say your hex has a single byte, the other bytes from the page it sits in will be read in from the device and the full page given to the programmer to write. I neither have the part nor the programmer, though.

@InspectorColombo?

[mcuee]

Unfortunately I can not reprodeuce the issue with an FT232 adapter which uses bitbang with avrdude 7.0 release or the latest git main.

However, from the prompt, we can see the latest git main writes 817 bytes and not 818 bytes. So I believe the issue is sorted out.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude7_msvc -C .\avrdude7.conf -c arduino-ft232r -p m168p
 -U .\Test_8535.hex

avrdude7_msvc.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude7_msvc.exe: Device signature = 0x1e940b (probably m168p)
avrdude7_msvc.exe: NOTE: "flash" memory has been specified, an erase cycle will be performed
                   To disable this feature, specify the -D option.
avrdude7_msvc.exe: erasing chip
avrdude7_msvc.exe: reading input file ".\Test_8535.hex"
avrdude7_msvc.exe: input file .\Test_8535.hex auto detected as Intel Hex
avrdude7_msvc.exe: writing flash (818 bytes):

Writing | ################################################## | 100% 50.61s

avrdude7_msvc.exe: 818 bytes of flash written
avrdude7_msvc.exe: verifying flash memory against .\Test_8535.hex:
avrdude7_msvc.exe: input file .\Test_8535.hex auto detected as Intel Hex

Reading | ################################################## | 100% 54.59s

avrdude7_msvc.exe: 818 bytes of flash verified

avrdude7_msvc.exe done.  Thank you.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_msvc -c arduino-ft232r -p m168p -U .\Test_8535.hex

avrdude_msvc: AVR device initialized and ready to accept instructions
avrdude_msvc: device signature = 0x1e940b (probably m168p)
avrdude_msvc: Note: flash memory has been specified, an erase cycle will be performed.
              To disable this feature, specify the -D option.
avrdude_msvc: erasing chip
avrdude_msvc: reading input file .\Test_8535.hex for flash
              with 817 bytes in 1 section within [0, 0x330]
              using 7 pages and 79 pad bytes
avrdude_msvc: writing 817 bytes flash ...

Writing | ################################################## | 100% 61.85 s

avrdude_msvc: 817 bytes of flash written
avrdude_msvc: verifying flash memory against .\Test_8535.hex

Reading | ################################################## | 100% 46.57 s

avrdude_msvc: 817 bytes of flash verified

avrdude_msvc done.  Thank you.

[mcuee]

@InspectorColombo

Please help to try the latest git to see if it sorts out the issue for you. Thanks.

I will close the issue in the end of Jan 2023 if I do not hear any news. In that case, you can still re-open the issue if there are still issues. Thanks.

[stefanrueger]

It is vvv likely this has been solved with PR #1265, which applies to all programmers that do not offer paged read/write such as par and serbb, both of which are used for the PonyProg device.

[mcuee]

@dl8dtl

Just wondering if you can test avrdude 7.1 release against this issue, with the parallel port programmer and ponyser programmer you have. Thanks.

[mcuee]

@InspectorColombo

Just wondering if you have time to revisit this topic to see if the issue has been resolved. Thanks.

[stefanrueger]

I think that can be closed... confident PR #1265 worked.