2017-12-04 11:38 AM
We are currently running an application on an STM32F207 MCU. We are using the first two sectors of flash for a bootloader and the rest for our actual application. We are are write protecting the bootloader sectors during initialization of our application.
We received a returned field unit with very little detail of what was happening/when the failure occurred. But on the surface it looked like a FW Update was unsuccessful and afterward the STM had been fully erased.
The way our update process works is we have another micro that transfers the STM application image to the STM and the STM saves it to some 'temp' sectors and jumps into the bootloader, which obviously applies the update to the application area sectors. We do not change the WRP option bytes anywhere else but setting the write protection in the application initialization (as stated above).
When we received the unit back from the field, using the ST-Link utility I can see that the whole Flash has been erased and looking at the option bytes, the first 2 sectors still have the write protection enabled. So I'm a bit of a loss here, and was curious if something like this has been seen before?Thanks!
2018-01-31 08:29 AM
Can I get any response to this inquiry? I suspect and RDP getting set from 0 -> 1 -> 0 as the cause, but my application and bootloader don't even have the functionality to do this explicitly so wondering how/if this could possibly happen? I was able to get the RDP from 0 -> 1 by a hard reset while the option bytes are being updated, but unable to get to a condition where it goes from 1 -> 0. So looking for any sort of guidance here?
2018-01-31 10:47 AM
>>Can I get any response to this inquiry?
This is a peer-to-peer forum, for engineering support contact the FAE assigned to your account, or push in via the normal sales/support channels.