search

gicking / stm8gal

PC tool for uplading hexfiles to the STM8 microcontroller via UART or SPI , using the built-in ROM bootloader. Works under Windows and Posix operating systems
Apache License 2.0
80 stars 21 forks source link

Does not handle 64K devices in bsl_getInfo() #19

Closed basilhussain closed 3 years ago

basilhussain commented 3 years ago

The bsl_getInfo() function in bootloader.c attempts to determine memory size of the device by reading from the last byte of flash. I notice that it does not have a case for 64K devices. I believe this will mis-classify some 64K devices as having 32K of flash memory and being 'medium density' devices, when they should be 'high density'.

For example, the STM8AF5288 is a 64K device and is classified as 'high density'. See Table 1 (pg. 6) of UM0560. ST's website product page also says this: "They are referred to as high density STM8A devices in STM8S series and STM8AF series 8-bit microcontrollers reference manual (RM0016)".

I think this will lead to stm8gal incorrectly erroring with an "unsupported device" message, when in fact it should install the RAM routines for a 128K device (further evidenced by the ROM BL of a STM8AF5288 being byte-for-byte identical to a STM8S208).

gicking commented 3 years ago

I believe there is no issue with this approach. Reason is that the 64kB device is only a test option of the 128kB device, i.e. they use the same chip internally. Consequently a read to >64kB should succeed and the 128kB RAM routine is correctly used.

However, I haven't tested it yet. But I have a "STM8A Discovery" board available which uses a STM8AF5288 (64kB). It seems like I need a USB<->LIN adapter for serial communication, so that may take a bit...

Having said that, I also don't like the way how stm8gal detects the STM8 variant and memory size by reading from certain addresses and checking for error. But it's the only method I could come up with. If anyone knows e.g. a secret flash address which contains the device type, I would gladly use that instead...

Am 11.12.20 um 16:05 schrieb Basil Hussain:

The |bsl_getInfo()| function in bootloader.c attempts to determine memory size of the device by reading from the last byte of flash. I notice that it does not have a case for 64K devices. I believe this will mis-classify some 64K devices as having 32K of flash memory and being 'medium density' devices, when they should be 'high density'.

For example, the STM8AF5288 is a 64K device and is classified as 'high density'. See Table 1 (pg. 6) of UM0560. ST's website product page https://www.st.com/en/microcontrollers-microprocessors/stm8af5288.html also says this: "/They are referred to as high density STM8A devices in STM8S series and STM8AF series 8-bit microcontrollers reference manual (RM0016)/".

I think this will lead to stm8gal incorrectly erroring with an "unsupported device" message, when in fact it should install the RAM routines for a 128K device (further evidenced by the ROM BL of a STM8AF5288 being byte-for-byte identical to a STM8S208).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/gicking/stm8gal/issues/19, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACOJF2VQRGWYVGE4TYKNJXTSUIYLJANCNFSM4UWYHTFQ.

basilhussain commented 3 years ago

Hmm, that does seem a bit 'dangerous' (for want of a better word) to assume that a read from >64KB will work successfully and result in the device being classified as high density. Who knows if in future that ST may change the behaviour of the chip, and reads past the 'official' end of flash fails?

Having had our separate discussion about the 1-byte 'patch' RAM erase/write bootloader routine for low-density STM8L devices, I also think this same issue may potentially pose a problem for such devices with less than 8K. There are some 4K devices - for example, the STM8L151G2. stm8gal might falsely declare "unsupported device" if it doesn't get the bsl_getInfo() check right for these.

MarkStokes71 commented 3 years ago

For what it's worth, I do have confirmation from ST Micro that devices 32k, 64k, and 128k have the same die. The only difference is the testing. 128k devices being tested for the entire memory size. So, the declaration of a 64k device as a 128k device for the purpose of loading the correct image is accurate (Also verified w/ STMicro). There is information available in some "secret" locations that will absolutely determine which size is validated, but that requires an NDA. I have seen it, so I know it exists, but being under an NDA, I cannot divulge the details of how it works.

gicking commented 3 years ago

@Mark: I believe your ST contact mixed something up: the STM8S "medium density" (16kB, 32kB) and "high density" (64kB, 128kB) definitely have separate dies. However, the 64kB and 128kB chips have the same dies, just tested differently. This was confirmed by ST support, and also by the fact that stm8gal can write and read up to 128kB to/from a "64kB device"

So here's the picture:

Having said that - and since I have no details about the "secret" device identifier you mentioned - I see no other way to detect the device type than checking if READ commands to certain addresses fail. Specifically:

Of course the "problem" with this method is that I cannot distinguish between a 16kB and 32kB device, respectively a 64kB and 128kB, as the ROM-BL doesn't reject r/w/e access to the untested flash pages.

But again, as I see no other method to detect the device type without breaking a NDA, I will close this issue for now. If someone can come up with an idea I'm happy to re-open it again...?

Have a great day