cancel
Showing results for 
Search instead for 
Did you mean: 

Using stm32flash with -S option (i.e. offset) but get a error message

cgarland42
Associate III

Using stm32flash -a0x51 -w binary.bin -S 0x3000 /dev/i2c-4

but get back

Failed to write memory at address 0x00003000

For 0x8003000 I get

Erasing memory

Page-by-page erase error.

Failed to erase memory

Any solution...can move offset i.e. bootloader offset. I don't believe sector are issue?

1 ACCEPTED SOLUTION

Accepted Solutions
cgarland42
Associate III

I have two solutions.

  1. Fix stm32flash...working on it.
  2. Using bootloader which will erase application area, bootloader is write protected. Then pad application binary with 0xFF, so without offset it write over bootloader and then application area. Bootloader being write protect does not get clobbered. Can't using it with -v but bootloader does CRC checking next time it boots.

View solution in original post

7 REPLIES 7
cgarland42
Associate III

It turn out, looking at https://sourceforge.net/p/stm32flash/tickets/98/ 

at the bottom in answered:

"I tried with an STM F0 Discovery board (STM32F072) which supports both interfaces, and erasing works fine over USART, but both mass erase and page erase fails over I2C." by Anders Montonen 2017-08-01

So basically it does't work for I2C.

Amel NASRI
ST Employee

Hi @cgarland42​ ,

Why don't you switch to STM32CubeProgrammer?

It supports various bootloader interfaces like I2C and it is possible to use it in command line besides to the GUI interface.

Please refer to UM2237 for more details on how to use this tool.

-Amel

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

For open source software/support you're likely going to need to be opening the source, and understanding it. Perhaps make a contribution to the dev to obtain some goodwill/support.

You'd want to double check the AN2606 and I2C boot loader protocol docs, and determine why it fails.

I'd analyze the ROM loader to understand how it works, and why it fails. I guess it really depends how keen you are to get this to work.

Worse case you could push a staged loader of your own into RAM, and make it do whatever you want properly.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Uwe Bonnes
Principal III

Did you update recently? Frequent need to update is a price to pay but also possibility of advantage with open software. But hey, that is from 2013!

commit 0eaf3999f5610b5f2da682acad8d0c26d5e72e2a

Author: Antonio Borneo <borneo.antonio@gmail.com>

Date:  Sun Nov 10 12:10:26 2013 +0800

   main: fix address issue introduced by "-S"

   The commit 279d3ce6c7a3d6088f201279940280a12024459d

   introduces few issues:

   - address passed with "-S" is sometimes used as absolute

     address, other as offset from flash start.

   - mass erase operation (special value npages=0xff) is not

     any longer the default.

Great tool, used it to confirm the issue I was seeing with ST debugger. Is small compact version that I can cross compile for embedded linux?

Will have ago fixing it.

Thanks.

cgarland42
Associate III

I have two solutions.

  1. Fix stm32flash...working on it.
  2. Using bootloader which will erase application area, bootloader is write protected. Then pad application binary with 0xFF, so without offset it write over bootloader and then application area. Bootloader being write protect does not get clobbered. Can't using it with -v but bootloader does CRC checking next time it boots.