-
Notifications
You must be signed in to change notification settings - Fork 184
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
Comments
There's also the STNRG and STLUX ROP byte. The documentation looks like they should behave like the STM8S. Philipp |
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 |
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
Examination of the output file (stm8s103_opt) shows it has the following contents 2a) Create a single byte file with the value required to be written to the 1st option byte (the ROP byte) 2b) and write the contents of that file to the device 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 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 Mike |
There is some additional memory space over standard Option Bytes. But it is MCU-dependend ( for example STM8S005: 0x4810 - 0x483F ):
|
ROP unprotection enforces uploading remaining default Option Bytes - othercase STM8S / STM8AF flash programming does not work properly. For example STM8S103 protection:
STM8S103 unprotection:
|
$ echo "00" | xxd -r -p >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/ |
Hi bWildered1 I had tried your suggestion for Philipp that you commented on 27 Aug 2017, Thank you! James |
@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. |
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
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
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
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
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
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).
The text was updated successfully, but these errors were encountered: