STM32 Lock up Issue

[HShah.7]

Dear All,

We are using STM32407 and NXP K60 in our product with our bootloader issue is when our app region is completely erased and we try to jump to app code the stm32 gets locked completely whereas Nxp k60 handles this issue by its Cpu lock up mechanism and generates RESET since app code does not have any fault handler code due to being erased.

Is there any way for stm32 to take care of this without using watchdog(internal/external)....we cant find anything in reference manual to tackle this scenario like NXP K60(Lockup reset) does. Kindly, guide

Any kind of suggestion/way around are welcomed.

regards,

MHS

[Pavel A.]

If app region is erased, don't jump there. This is responsibility of the bootloader. The watchdog may be helpful too - why not to use it?

-- pa

[HShah.7]

Actually, explaination will take too long....but we want the stm32 to get reset if app code is erased or corrupt...right now we are trying to avoid watchdogs.. once mce gets resets again we may handle it like we do in NXP K60 due its lock up reset mechanism...does stm32 have any feature.

On Tue, 23 Oct 2018, 1:30 am ST Community wrote:

[Bob S]

As @Pavel A.​ said - don't do that. The bootloader should never jump to application code that it cannot verify as valid. I may have tunnel vision but I cannot see a use case where that should be allowed.

But if you insist on being masochistic, the bootloader could enable the MPU and don't allow execution outside the bootloader and expected application memory areas. It has (thankfully) been a while since I've dealt with run-away program counters, but I *think* that the STM32 will interpret erased flash as some non-branching instruction, so it will try to execute from ever increasing addresses. The MPU needs to stop that before the program counter gets to un-mapped memory areas or the peripheral blocks (which will be interpreted as who-knows-WHAT kind of instruction.

[Tesla DeLorean]

The trick is to have a loader you don't erase, ever. And the validates code images before ploughing forward.

Some of us had to write code solidly that could be ROMed back in the day, screwing up wasn't an option the bosses accepted. You learned not to fail and avoid the Edison method of software development and deployment.