STM32L151 setting RDP=1 prevents update via user bootloader (Boot From Flash)

[Clifford1]

I have a user bootloader I have used across various STM32 parts over 12 years. In production RDP level 1 is enabled and this has always been fine for various STM32F1, F2, F4 based products we have in production, and for thousands of units in the field. However on a new product using an STM32L151C8T6A, setting RDP prevents update via this bootloader.

The bootloader uses XMODEM-1K over UART - the target emits the "C" start character and starts the update of the application area if the host responds to the start character before a timeout. With RDP=0, this process works as expected. With RDP=1, the first XMODEM-1K packet is sent in response to the "C" start byte, but it is ignored (i.e. no ACK, NAK or CAN) and the existing unmodified application boots. I do not believe that the processor is resetting, because that would cause the "C" to be emitted again, rather it seems to be ignoring the XMODEM-1K packet, and booting after timeout.

There is no JTAG/SWD connection, and nothing connected on-board to the debug port pins. Nothing in the documentation suggests to me that this should not work, and as I have said, I have been using this bootloader method over many products using STM32 variants for over 12 years.

Below is an example (from Advanced Serial Port Monitor in "Spy" mode) of the first packet being ACK'ed (white 06) when RDP=0, and the next packet following on:

and here, the same packet being ignored when RDP=1:

The target output (white) is junk because the application outputs at 38400 where the bootloader runs at 115200, but it indicates that the application is being started by the bootloader without resetting (which would emit 'C' / 0x43 at 115200). These images are not necessarily helpful in diagnosing the issue, but are provided to indicate the differing behaviour is real not imagined 😉

BOOT pin configuration:

 

Any ideas welcome - is there something different about the L1xx that would cause this to differ from other parts? (I have already encountered and dealt with the erase to 0x00 rather than 0xFF, "gotcha" so I am wary that there may be other differences I have not considered.

[Bob S]

What would cause your bootloader to ignore the incoming data? Or, conversely, what would cause your bootloader to see the incoming data, try to program it, fail and then go ahead and run the existing program instead of returning an error and/or looking for more XMODEM data? While the RDP setting might be the difference that triggers this behavior, seems like some error condition or abnormal behavior isn't getting caught by the bootloader.

Is the RDP setting the ONLY difference?

[Clifford1]

Indeed, and I am waiting the slap-head moment of realisation, but given this is code that has worked on other STM32 variants for years, I am seeking differences in particular with the STM32Lxxx.

That is not to say of course there might not be some long standing "undefined behaviour" in the code that is an issue. But the observations do not fit that hypothesis at the moment.

W.r.t. RDP being the only change, yes. I can for example load the production release hex file in CubeProgrammer (so there are no dev tool dependencies) via ST-Link (also as used in production), and can then load and reload an application hex file via the bootloader without issue. Then if I set RDP, without changing the loaded code, the bootloader no longer works as described.

If I then set RDP=0 and reload the code from the same hex file, it starts working again.

Equally if I bulk erase the chip, reset all option bytes, load the hex file and set RDP all in cube programmer, so it is as if it were straight from production, the bootloader will not work at all.

For the moment, this particular application does not contain critical IP, and it only works in conjunction with another product which is protected, so for the time being we are building without RDP enabled, but it is somewhat unsatisfactory.

[InsignificantBit]

I am not aware of any obvious difference between F1/F2/F4 and L1 series, which might explain failing IAP flash programming *only* at RDP level 1, unless you have a really old revision of the chip and are experiencing a bug number 2.2.2 - "Undefined instruction exception during IAP". In either case, refer to the errata sheet for die revision identification and a workaround.

What I think is a little more likely is that you might be programming the option bytes incorrectly, or more specifically, that you are erroneously modifying the SPRMOD bit which is right next to RDP bits in option bytes, and which does differ in its placement between L1 and F4.

As a sidenote, please note that the entire STM32L1 currently has "Not Recommended for New Design" status. If you are choosing a new microcontroller for your application, I recommend choosing from a newer family.

[Clifford1]

Thanks. I'll investigate those points, but given that I am using STM32CubeProgrammer to set the RDP, I cannot imagine that erroneously setting adjacent bits is the issue.

The error you referred to appear in the STM32L151x6/8/B STM32L152x6/8/B errata. This is for an STM32L151C8-A, and the applicable errata or -A devices: (STM32L151x6/8/B-A STM32L152x6/8/B-A) does not have that issue.

w.r.t. "NRND" that may not have been the case when this project started 😉 It is new code on an existing design in any case. We have appropriate supply guarantees for the volumes and lifetime we expect.