-
Notifications
You must be signed in to change notification settings - Fork 21
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
allow to program the option bytes #6
Comments
hi Michale, using option "-x" stm8gal already deactivates the bootloader via option byte (and it's complementary). Via bootloader this is identical to writing other flash memory. So adding this is VERY simple, the question is mainly the "user interface"
What would you prefer? Regards, Georg |
I just compared the datasheets of STM8AF52xx and STM8L101xx, and unfortunately the option bytes don't match. In addition the STM8L does not require the complementary value, probably to save a few bytes... :-( |
stm8flash treats the option bytes simply as a generic memory area that can be read and written. It is the users responsibility to format the content accordingly. Maybe something similar for stm8gal? Using stm8flash looks like this:
How about an option "-s "? It could default to flash memory if not given. This allows for easy extensions in the future e.g. for EEPROM access. If you decide to add a device type specifier anyway (because of the uart mode issue) It would be possible to integrate the knowledge about the exact memory layout into stm8gal and allow a more user-friendly interface similar to the fuse definitions with avrdude:
But I am not sure if this is really better than a generic interface similar to stm8flash. |
I prefer option 1 because it matches the procedure in stm8flash, and also because I don't plan to add a device specifier for the uart mode issue . Besides the many different supported options would just blow up stm8gal. Do I understand correctly that file Alternatively how about writing option bytes from a hexfile with proper address and value...? Such a hexfile could be easily created from an ASCII-table using hexfile_merger. And as a positive side-effect I wouldn't need to change stm8gal ;-) |
I am not sure if only setting the target address is enough. I think the access needs to unlocked first by a magic sequence and two special bits need to be set in the flash control registers. (rm0016, sec. 4.4.6, page 43). But sec. 4.6.5 (page 49) gives hope: "Option byte programming is very similar to data EEPROM byte programming". I guess there is a reason why the guys at stm8flash add a special option for this memory area (but I don't know for sure). Reading the option byte area of an unlocked STM8S103F3P6 without any option bits set (on Mint 19) looks like this:
Or in binary mode:
|
you are correct about unlocking option byte range. However, this is apparently taken care of by the bootloader or the RAM routines already. Because if you look at
and As said, the main question is the "UI", not the actual writing of the option bytes. But let me check again |
my current idea is to write option bytes just like a "normal" hexfile. Already tested it and it works :-) Procedure:
I understand that calling an extra tool is inconvenient, but that can be overcome rather easily by adding an import filter for plain tables (like this). Then changing option bytes becomes as easy as RTFM... ;-) I actually prefer this method over cryptic commandline parameters, because it is more transparent. But what do you think? IMHO the only disadvantage is that But first things first: is changing option bytes via plain ASCII tables the way to go? Please let me know what you think. Thanks in advance! PS: By the way, as the memory dumps from steps 3+5 have the same format as the import file in step 1, they are convenient starting points for option byte setups :-) |
add examples for changing option bytes, see #6
Sound like a good start. I will try it next week. Would it be possible to support using the txt files as input files directly? It would be a custom hex file format. Instead of
How about supporting raw binary data as input? That would save the conversion step to s19. The address transformation can be handled by either specifing a memory type (like |
yes, I plan to support both ASCII tables and binary data as input format. Then changing option bytes becomes very easy. My current idea is like this: ASCII Table:
Binary File: Let me know what you think :-) PS: one more question: I remember that Cosmic allows to specify static data with address. That is how I used to set option bytes from within a project without having to change them only. Unfortunately I don't recall how this is done, but does SDCC allow this as well? If yes, that is yet another option, i.e. encapsulated in the resulting build output. At least I should point out this option in the |
ASCII table seems to work now, see branch "addTableAndBinary". Please try and let me know. Thanks in advance! Syntax is same as before ( |
just uploaded branch "addTableAndBinary" which now allows multiple uploads (and downloads) in one run. In addition it is now possible to change a value in flash or RAM directly (option -s), or via an ASCII table (*.txt). That way option bytes (or any other memory) can be changed easily. Note however, that inconsistent option bytes (NOPT != OPT^0xFF) result in an endless reset cycle, i.e. bootloader is effectively disabled --> recover requires SWIM and stm8flash. Therefore always change option bytes pairs if applicable (is device dependent) Please let me know what you think of this. Also please let me know if the previos UART mode detection is working for your boards...? Thanks a lot in advance! |
Writing option bytes works in v1.3.0 via hexfiles, binary files or files with plain text, e.g.
Warning: use option bytes with cary! If OPT and NOPT (=inverse) bytes don't match. the STM8 stays in an endless reset cycle. This condition can only be fixed via SWIM interface. |
add examples for changing option bytes, see gicking#6
It would be useful to be able to access and modify the option bytes using stm8gal. Especially the ROP (read out protection) bit for unlocking a locked MCU is important.
The text was updated successfully, but these errors were encountered: