Support for STVP option byte hex format?

[martonmiklos]

Hello all,

As far as I know the only graphical option byte editor is the STVP. Unfortunately it saves the option bytes in a weird format:

:01480000AA0D
:0148010000B6
:0148030001B3
:0148050010A2
:0148070000B0
:0148090000AE
:00000001FF

(This is a file saved for an STM8S003F3.)

If you take a look on the HEX above you can see that all negated option bytes left out from it.

When the stm8flash opens such a file it will fill only the addresses present in the hex file leaving the negated bytes uninitialized.

Since we have no access to royalty free database* of the registermaps I would either recommend to implement the following "hack":

If the hex file read for option byte programming and single byte "holes" found between values fill them with the negated value of the previous byte. If a single byte is missing from the end of the option area that should be also negated from the last-1th byte.

Let me know if you have any better idea!

* The STVD ships with some password protected MDB files where this information could be obtained. (We can look for the register name pairs in the option area with and ) If you have no objections about it I can extract and patch the stm8.c file with those data .

I have checked the STVD/STVP mdb files and only the option byte addresses are present there (they have no info on the negated ones). So I assume that they simply program the next bytes with the negated values for the option bytes.

[xtlc]

I am having the exact same problem with that chip. I got surprised to always read "10 bytes at 0x4800 .. OK". The STM8S003F3 has 11 bytes and the file with no options set looks like this (ROP is on, AA in the first line instead of 00, last line is checksum).

:01480000AA0D
:0148010000B6
:0148030000B4
:0148050000B2
:0148070000B0
:0148090000AE
:00000001FF

Is there any known workaround to flash the opt bytes? Right now if I do stm8flash -c stlinkv2 -p stm8s003f3 -s opt -w ROP_ON.s19 The device stops working. I have to erase it after that, before I can flash it again. If I flash it all the way with stm8flash and just set the opt with STVP it works like a charm - but I want to use only one software if possible.

[martonmiklos]

As mentioned above the if you look your hex all odd addresses (where the negated OPT bytes are).

If you fill them with the negated ones it going to work.

:0B4800000000FF01FE10EF00FF00FFB2
:00000001FF

If you flash this above it will deactivate ROP and set some alternate functions, but your MCU will work and be programmable.

[xtlc]

@martonmiklos thanks for your comment. Can you describe how you changed :01480000AA0D into :0B4800000000FF01FE10EF00FF00FFB2? Should it not start with :**01**48000000**0D**FF01FE10EF00FF00FFB2 or sth similar? I must admit I can not follow how you created that line, would you care to elaborate?

[martonmiklos]

@xtlc

The hex what I have pasted is not identical to your option byte config, I have just copied a known-to-be-working-with-stm8flash option byte hex from one of my projects.

What I wanted to highlight, is the fact that it covers all the 11 bytes bytes from 0x4800 to 0x480A while your config only covers the even addresses. 0x4800, 0x4801, 0x4803 (6 bytes).

Set all your even (0x4802, 0x4804...) bytes to the complemented one of the previous address's value and stm8flash will program your option bytes without any problems. This could help you to calc the checsum: https://www.fischl.de/hex_checksum_calculator/

As the datasheet says:

Except for the ROP (read-out protection) byte, each option byte has to be stored twice, in a regular form (OPTx) and a complemented one (NOPTx) for redundancy.

[xtlc]

In case anyone reads this and asks himself how this works for the stm8s003f3: :044800AA09 :04480100B2 :044802FFB2 :04480300B0 :044804FFB0 :04480500AE :044806FFAE :04480700AC :044808FFAC :04480900AA :04480AFFAA :030000FC Every second row (except the first) is the negated bit from the former line. I guess the last line is not so important, this worked for me.

[stefaandesmet2003]

@vdudouyt @spth There is an interesting hint in this discussion. The mentioned database file shows how an automatic device identification can be done. This would allow to eliminate the -p command line parameter altogether, and avoid some common mistakes leading to 'tries exceeded' error. Is there interest for a pull request along this line?

[spth]

AFAIK, some devices are identical, except for the size of some of the memory, or peripherals, possibly they are using the same die, binned according to what works / what there is market demand for. So I don't think I'd want to eliminate -p now (otherwise users would non-knowingly exceed the program memory size their device is rated for, and then run into hard-to-debug bugs when part of their program ends up in bad memory that failed testing).

But, I think a pull request for the following autodetection could be very welcome:

• Emit a warning when the autodetected device is incompatible with the one specified via -p.
• Add an option to do use full autodetection (maybe -p auto or --auto or whatever)

[stefaandesmet2003]

good approach. I'll make something along this line. You are right, for some devices in the list, different flash sizes have the same id. Not sure if this is wanted, but with a few dummy writes we could figure out if the flash/eeprom/ram exists or not. I guess even for peripherals that might work, will give it a try. the autodetection will anyway not work when ROP is active.

[spth]

The risk here is that the flash / eeprom / ram / peripheral might be physically present, but have failed a test. I do not know how much testing ST does. Maybe they do more testing on the STM8A parts than on the other ones. There are faults, that a simple write-then-read test test at room temperature, as we could do won't catch. E.g. a test that writes at a lower voltage, then reads at a higher one, possibly at the upper end of the rated temperature range, might find memory bits that are unreliable (and under normal conditions would appear to work fine at first, but possibly have bit flips within a few months rather than after the rated 20 years of data retention). Still, we might try autodetection, if explicitly requested by the user; possibly give a warning where we can't be sure.

[martonmiklos]

Hi folks,

I am not sure how the topic was hijacked from the original "STVP option bytes hex format support" but I assume the mention of the MDB files was the key ;-).

What I personally would find to added value from this is generating the stm8_devices struct array from the mentioned MDB files. Chip auto detection is something what is nice but for e.g. I actually nearly never use. What could be useful in this area is generating the bash tab competition for the -p option.