How to program config data in a read-protected device

[M F]

Posted on July 13, 2017 at 18:04

Hi all,

I am using the STM32L011G3U6 with 8kB FLASH.

We deliver this chip programmed with a firmware that is read protected (RDPROT = Level 1)

Our customer should be able to write certain data in predefined non-volatile memory (let's say EEPROM) to control certain firmware parameters (for instance, how often a LED blinks).

This configuration programming is neither via ST-LINK, my preferred method, nor Bootloader UART commands possible since memory is protected.

I cannot separate the code from the program data and then read-protect the 4kB code-sector via WRPi bits in Optional Bytes. My code is 6,5kB with compiler option armcc compiler option set to -O3 (the highest optimization possible).

To avoid the former data/code separation there is a compiler option:

armcc --no_literal_pools --max_string_in_code=0

recommend it in

http://www.st.com/content/ccc/resource/technical/document/application_note/b4/14/62/81/18/57/48/05/DM00075930.pdf/files/DM00075930.pdf/jcr:content/translations/en.DM00075930.pdf

 

but it did not work.

My firmware did not react.

My only idea would be to implement a UART command interpreter that receives customer commands with the address and value to program in memory.

Any other idea?

Thanks a lot for your input.

#read-protection #rdprot #program-memory

[Tesla DeLorean]

Posted on July 13, 2017 at 18:26

The ST-LINK isn't going to be able to read anything back, which might impede the use of the utilities.

Do the system board loader commands work when you send them to the board? Not using the L011, but seem to recall the loader should support a subset of commands even with read-out locked? Did you write your own app to talk to the system loader?

By far the most preferable method is to provide a serial based user interface (console/menu) where you can send and write the data in a robust/secure manner.

[M F]

Posted on July 14, 2017 at 13:21

Hi, Clive,

thanks for fast answer.

according to the AN3155, USART protocol used in the STM32 bootloader, the bootloader cannot write in FLASH memory if RDP is active.

But there are a couple of commands that keep active (the ones marked with (2) in the table) 

My firmware does not communicate with the bootloader (I actually do not know how to do it). Could you expand your idea?

Thanks

[Tesla DeLorean]

Posted on July 14, 2017 at 18:09

Not the firmware, the PC side application, ie equivalent to 'Hex Loader Demonstrator'

http://www.st.com/en/development-tools/flasher-stm32.html

 

I've used RealTerm in Hex mode to walk commands into the System Loader.

There was an SPI STM32 Hosted example using the loader protocol, but that was for a secondary device. I've had other STM32 where I jump into the System Loader from the application, but that is still predicated on the loader responding to Write commands, etc. I haven't had cause to disassemble the L0 loader, but like I said, other ones I'm pretty sure still had write working, but it's not something I'm actively investigating.

The best user experience will be you providing a means to send the user configuration/calibration data, which you control/manage directly in your firmware.