#140 stm32flash 0.6 not working with STM32F103VG

[Stefan Wagner]

I updated stm32flash from version 0.5 to 0.6 and found that it is not responding for 25 minutes with my STM32F103VG controller and nothing is written to the controller.

The used commandline is

stm32flash -i 65,64,-65,65:65,-64,-65,65 -b 57600 -w test.hex -v -n 10 /dev/ttymxc4
stm32flash 0.6

http://stm32flash.sourceforge.net/

Using Parser : Intel HEX
Interface serial_posix: 57600 8E1

GPIO sequence start
 setting gpio 65 to 1... OK
 delay 100000 us
 setting gpio 64 to 1... OK
 delay 100000 us
 setting gpio 65 to 0... OK
 delay 100000 us
 setting gpio 65 to 1... OK
GPIO sequence end

Version      : 0x30
Option 1     : 0x00
Option 2     : 0x00
Device ID    : 0x0430 (STM32F10xxx XL-density)
- RAM        : Up to 96KiB  (2048b reserved by bootloader)
- Flash      : Up to 1024KiB (size first sector: 2x2048)
- Option RAM : 16b
- System RAM : 6KiB
Write to memory
Erasing memory
Failed to read ACK byte
Page-by-page erase failed. Check the maximum pages your device supports.
Failed to erase memory

GPIO sequence start
 setting gpio 65 to 1... OK
 delay 100000 us
 setting gpio 64 to 0... OK
 delay 100000 us
 setting gpio 65 to 0... OK
 delay 100000 us
 setting gpio 65 to 1... OK
GPIO sequence end

The reason I found for this is commit 5dbb767b.

It causes the call of stm32_pages_erase instead of stm32_mass_erase as in version 0.5. Inside that function stm32_pages_erase function call s_err = stm32_get_ack_timeout(stm, pages * STM32_PAGEERASE_TIMEOUT); times out after 25 minutes. The pages is 300 in my case. The STM32F103VG has 512 flash pages.

When I revert that commit the controller is programmed correct.

In my case stm32flash is running on an NXP iMX6 with Kernel 4.14.167.

[Tormod Volden]

Thanks for the report. First, the value of 5 seconds(!) for STM32_PAGEERASE_TIMEOUT (as introduced in commit 256fdb31) sounds like a lot, but maybe some older devices are that slow.

However, the problem here is that the device is not returning an ACK within this time (25 min) after a page erase has been issued. I suppose your 25 minutes wait is between Erasing memoryand Failed to read ACK byte? Page erase (normal or extended) should be supported on all devices.

Please compile and run latest git, because the error messages has been changed a bit.

[Stefan Wagner]

Yes, the wait is between Erasing memory and Failed to read ACK byte.
I also have to correct myself, the size of the hex-file equals 350 flash-pages.

I compiled now commit e27a8f which results in this output:

stm32flash -i 65,64,-65,65:65,-64,-65,65 -b 57600 -w test.hex -v -n 10 /dev/ttymxc4
stm32flash 0.6

http://stm32flash.sourceforge.net/

Using Parser : Intel HEX
Location     : 0x8000000
Size         : 716652
Interface serial_posix: 57600 8E1

GPIO sequence start
 setting gpio 65 to 1... OK
 delay 100000 us
 setting gpio 64 to 1... OK
 delay 100000 us
 setting gpio 65 to 0... OK
 delay 100000 us
 setting gpio 65 to 1... OK
GPIO sequence end

Version      : 0x30
Option 1     : 0x00
Option 2     : 0x00
Device ID    : 0x0430 (STM32F10xxx XL-density)
- RAM        : Up to 96KiB  (2048b reserved by bootloader)
- Flash      : Up to 1024KiB (size first sector: 2x2048)
- Option RAM : 16b
- System RAM : 6KiB
Write to memory
Erasing memory
Failed to read ACK byte
Extended erase failed. Check the maximum pages your device supports.
Failed to erase memory

GPIO sequence start
 setting gpio 65 to 1... OK
 delay 100000 us
 setting gpio 64 to 0... OK
 delay 100000 us
 setting gpio 65 to 0... OK
 delay 100000 us
 setting gpio 65 to 1... OK
GPIO sequence end

[Tormod Volden]

I tested page erases on a STM32F103 myself, so I would be surprised if it is not supported. Can you please try another, small hex (or binary) file? Can it be that the page numbers are wrongly calculated? Can you please check which arguments are passed to stm32_pages_erase()?

[Tormod Volden]

Please see commit e1536da2 - we limit the number of pages per request to 511. Maybe this chip doesn't even support this number? Can you try changing the limit to e.g. 256, 255, 128, or 127?

[Stefan Wagner]

I created a script to generate hexfiles with different sizes. I nailed it down to 154 pages.

[Stefan Wagner]

With commit e27a8f this call is working:

stm32flash -i 65,64,-65,65:65,-64,-65,65 -b 57600 -w test_314368_byes.hex /dev/ttymxc4

this is failing:

stm32flash -i 65,64,-65,65:65,-64,-65,65 -b 57600 -w test_315392_byes.hex /dev/ttymxc4

With the patch above both are working.

[Stefan Wagner]

With this script I created the hexfiles above. I used a simple blinky as base hexfile and attached 0xAA until the specified size.