STM8 ROP Option Byte

[bWildered1]

Attached is a document that attempts to put the Read-out Protection (ROP) option byte information for all STM8 devices in one place.

The mechanism to disable ROP varies between STM8 types, and sometimes within the type.

The documentation is not as clear nor as consistent as it might be, and this can lead to confusion.

This information does not concern itself with any other option byte, in any way.

STM8_ROPOptionByte.xlsx

NB: This is the author's interpretation of the many and varied STM8 documentation; please satisfy yourself that the information following is correct

Attached is (hopefully, as this site would not allow an OpenOffice spreadsheet) an Excel spreadsheet showing the ROP option byte for the various devices within the STM8 families.

Here is a summary

1. STM8S ROP Option Byte
   Factory Default: 0x00
   Enable ROP: Write 0xAA to 1st Option Byte
   ROP Disable: Write a single byte that is NOT 0xAA (e.g. 0x00) to 1st Option Byte, then reset device

2. STM8AF ROP Option Byte
   Factory Default: 0x00
   Enable ROP: Write 0xAA to 1st Option Byte
   ROP Disable: Write a single byte that is NOT 0xAA (e.g. 0x00) to 1st Option Byte, then reset device

3. STM8AL ROP Option Byte
   Factory Default: 0xAA
   Enable ROP: Write any byte other than 0xAA (e.g. 0x00) to 1st Option Byte
   ROP Disable: 1st Option Byte, write 0xAA, read EOP, write 0xAA, read EOP

4. STM8L (except STM8L101xx) ROP Option Byte
   Factory Default: 0xAA
   Enable ROP: Write any byte other than 0xAA (e.g. 0x00) to 1st Option Byte
   ROP Disable: 1st Option Byte, write 0xAA, read EOP, write 0xAA, read EOP

5. STM8L101xx ROP Option Byte
   Factory Default: 0x00
   Enable ROP: Write 0xAA to 1st Option Byte
   ROP Disable: Write a single byte that is NOT 0xAA (e.g. 0x00) to 1st Option Byte, then reset device

Also note that the documentation for the STM8L052R8 device gives a factory default value of 0x00 for the ROP option byte; this differs from the other devices in the same series (although this could be an error in the documentation).

[spth]

There's also the STNRG and STLUX ROP byte. The documentation looks like they should behave like the STM8S.

Philipp

[spth]

What does this mean for stm8flash? How should stm8flash unlock? The current code sets all option bytes to 0 (i.e. different from thr factory default). But the STM8 documentation says that clearing the option byte triggers a global flash erase which results in loss of the factory default values anyway.

Philipp

[bWildered1]

Hi Philipp

You could conduct some experiments; thanks to the developers, stm8flash is a versatile tool.

I dug out an STM8S103F3 based module, and established the following

1. I read the option bytes using stm8flash
   stm8flash -c stlinkv2 -p stm8s103f3 -s opt -r stm8s103_opt

Examination of the output file (stm8s103_opt) shows it has the following contents
00 00 FF 00 FF 00 FF 00 FF 00 FF
with the very first byte being ROP (Read-out Protection); on the STM8S103F3 device, a value of 0x00 means ROP is clear

2a) Create a single byte file with the value required to be written to the 1st option byte (the ROP byte)
echo "55" | xxd -r -p > ROP_byte.bin

2b) and write the contents of that file to the device
stm8flash -c stlinkv2 -p stm8s103f3 -s opt -w ROP_byte.bin

2c) read back the option bytes from the device; examine to determine if the ROP byte, and only the ROP byte, has been changed to the value specified in the file
55 00 FF 00 FF 00 FF 00 FF 00 FF

I specified a value of 0x55 purely for test purposes as I did not want to set the ROP option byte.

In my experiment, the value of the ROP byte on the stm8s103f3 device used was 0x00 prior to the test, and 0x55 afterwards.

Naturally, the actual value written will be determined by the device used, as the value - and technique - used to set and clear Read-out Protection varies across devices.

You might find this a useful starting point.

Some devices seem to require more than one write to the ROP byte, checking EOP in between. I have not yet had an opportunity to experiment with those. I would imagine that checking EOP would not be strictly necessary if the command line is used, as per above, but would probably be essential if a shell script or similar is used.

The best tests would be done, of course, on those devices that have ROP set. If you are in a position to test any devices - particularly from different families (e.g. STM8L, STM8AL, etc) then a post with the technique used might well be of benefit to all STM8 users.

Take care
and good luck

Mike

[PiotrLenarczyk]

There is some additional memory space over standard Option Bytes. But it is MCU-dependend ( for example STM8S005: 0x4810 - 0x483F ):

*(unsigned char*)0x4810 = 0x01;
*(unsigned char*)0x4811 = 0x02;

[PiotrLenarczyk]

ROP unprotection enforces uploading remaining default Option Bytes - othercase STM8S / STM8AF flash programming does not work properly. For example STM8S103 protection:

*(unsigned char*)0x4800 = 0xAA; //protect
resetDevice();

STM8S103 unprotection:

*(unsigned char*)0x4800 = 0x00; //unprotect
*(unsigned char*)0x4801 = 0x00; //default
*(unsigned char*)0x4802 = 0xFF; //default complementary
*(unsigned char*)0x4803 = 0x00; //default 
*(unsigned char*)0x4804 = 0xFF; //default complementary
...

[mmilch]

$ echo "00" | xxd -r -p >ROP_CLEAR.bin
$ stm8flash -c stlinkv2 -p stm8s105?4 -s opt -w ROP_CLEAR.bin

Hi. I got ROP protected stm8s105s4 chip in e-bike controller and would like dump it's entire content (flash, eeprom and option memory). Is it 100% sure that doing above trick will result in a lost of original flash memory ?

[rumpeltux]

$ echo "00" | xxd -r -p >ROP_CLEAR.bin $ stm8flash -c stlinkv2 -p stm8s105?4 -s opt -w ROP_CLEAR.bin

Hi. I got ROP protected stm8s105s4 chip in e-bike controller and would like dump it's entire content (flash, eeprom and option memory). Is it 100% sure that doing above trick will result in a lost of original flash memory ?

Yes. But there are (complicated) ways to circumvent this: https://itooktheredpill.irgendwo.org/2020/stm8-readout-protection/

[cmchung1208]

Hi bWildered1

I had tried your suggestion for Philipp that you commented on 27 Aug 2017,
The only different is that I used stlink(not v2) & stm8s005x6
But the stm8flash doesn't work at opt part. (Part flash & eeprom works fine)
I want to use stm8flash to enable / disable ROP feature
Could you provide me some advise ?

Thank you!

James

[schneidersoft]

@cmchung1208 Can you get an stlinkv2? or get me an stm8s005x6 ;D ? I'm working on a fork of stm8flash and if you're willing to test I could get ROP to work for you.

[Finnn-glitch]

Hello yall, i have a similar situation as mmilch. Its not a Ebike controller, its a HDMI Splitter where i want to change the display name which is shown in the display settings under windows. The chip im using rn is STM8S003F3P6.
Would be great if someone would take a look at it :=)

[schneidersoft]

What exactly is not working? Stm8s003 should be working. You could also try my fork of stm8flash.

As mentioned already, resetting the rop will clear everything including opt bytes. You must write the option bytes to something valid before resetting the chip.

[spth]

Have you tried with an ST-Link/v2 or later yet? In general, ST-Link/v2 support in stm8flash tends to be better-tested and supported (e.g. the STM8S003 EEPROM is only supported with ST-Link/v2 according to the README.md).

[Finnn-glitch]

Hey i tried the stm8flash fork from schneidersoft.
The first command worked. Then i generated the file via python script and pasted the last file. I wasnt careful what chip was selected in the last command and my stm8 got wiped😁.

Ill grab another splitter and try again. Costs 6€.

[schneidersoft]

You should still be able to flash the opt bytes

…

On December 24, 2024 2:15:17 PM GMT+01:00, Finn ***@***.***> wrote: Hey i tried the stm8flash fork from schneidersoft. The first command worked. Then i generated the file via python script and pasted the last file. I wasnt careful what chip was selected in the last command and my stm8 got wiped😁. Ill grab another splitter and try again. Costs 6€. -- Reply to this email directly or view it on GitHub: #71 (comment) You are receiving this because you commented. Message ID: ***@***.***>

[Finnn-glitch]

In your Repo the Unlock example there are 3 commands. The bottom two are "One". Python script to generate the rop bytes and the command to write the bytes to the stm8. In your Example the stm8s208mb is mentioned. Ill guess i just replace it with my model? Thats what i didnt do instead i just copy pasted it into my terminal and it wiped the stm8.

[schneidersoft]

The two commands are separate because the generation of the opt bytes file is done in a separate step. Each micro/project may require a different opt file. You must generate such a file for your specific micro. The second command flashes the opt file. You must adjust both the opt file and command to fit your micro. Some micros will reject changes to the opt bytes if they don't follow a specific format. Check the data sheet of your model. Typically it's some registers that must be the xor of some other register. If you have a clean working chip you can read the opt contents to file and flash it to another. Changing the opt bytes is a little risky since you can accidentally do things like disabling swim or misconfigure clocks rendering the device useless.

…

On December 24, 2024 4:23:30 PM GMT+01:00, Finn ***@***.***> wrote: In your Repo the Unlock example there are 3 commands. The bottom two are "One". Python script to generate the rop bytes and the command to write the bytes to the stm8. In your Example the stm8s208mb is mentioned. Ill guess i just replace it with my model? Thats what i didnt do instead i just copy pasted it into my terminal and it wiped the stm8. -- Reply to this email directly or view it on GitHub: #71 (comment) You are receiving this because you commented. Message ID: ***@***.***>