Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

STM8 ROP Option Byte #71

Open
bWildered1 opened this issue Jul 25, 2017 · 9 comments
Open

STM8 ROP Option Byte #71

bWildered1 opened this issue Jul 25, 2017 · 9 comments

Comments

@bWildered1
Copy link

bWildered1 commented Jul 25, 2017

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
Copy link
Collaborator

spth commented Aug 25, 2017

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

Philipp

@spth
Copy link
Collaborator

spth commented Aug 25, 2017

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
Copy link
Author

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
Copy link

PiotrLenarczyk commented Aug 23, 2018

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
Copy link

PiotrLenarczyk commented Aug 23, 2018

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
Copy link

mmilch commented Jun 10, 2020

$ 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
Copy link
Contributor

$ 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
Copy link

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
Copy link
Contributor

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants