STM32L452 bootloader reset by PA0

[Krystof Vanek]

Hello,

I believe I have a rather curious situation. I was able to jump to the device embedded boot-loader (USB) which works nicely. However if button connected to PA0 is pressed (rising edge), the boot-loader reboots to main code. Pin PA0 is previously configured as EXTI0, but for example PA2 as EXTI2 does not reboot the boot-loader.

Does anybody know how is this possible? I would like to know as it is a VERY pleasant surprise for me and I would like to recreate such behaviour.

Thank you

[waclawek.jan]

Interesting.; however, if it's undocumented, I wouldn't rely on that it is intended and that it will survive to a next revision of the internal bootloader.

Does this occur on an erased mcu too?

> I would like to recreate such behaviour

I don't understand. Recreate this behaviour in *your* bootloader? Isn't that just too easy, to check PA0 and perform a software reset when it's at a certain level? Am I missing something?

JW

[Krystof Vanek]

Sorry, I forgot to mention it does NOT occur when I enter the boot-loader via hardware reset with BOOT0 pin high. From that information I deduce it has to be related to the firmware-bootloader handover. It is a "bug", however a very fortunate one :)

To clarify the statement "I would like to recreate such behaviour." :

I'm interested in such behaviour as the application basically has only two inputs - USB and button on PA0. Other inputs are accessible only after enclosure disassembly. Jump to the boot-loader is made as a response to command received via USB VCP. So if this is done by user mistake, there is no other way of easy (without DFU utility) return to main code. Except for this fortunate "mysterious" PA0 behaviour.

But it is exactly as you write.. it is impossible to count on an undocumented occurrence. I would like to get to know why is this happening so I could consider it a controlled feature.

[waclawek.jan]

You can debug the bootloader in disasm view, and try to ascertain what is going on.

It sounds like PA0 prevents the bootloader in resetting IWDG timely.

Try first without EXTI0, it may be a coincidence - if not, it is a clue.

JW

[Krystof Vanek]

Thank you very much for you opinions, they are indeed very helpful.

I did few things to further investigate what is happening.

1) > Debug the boot-loader in disasm view

I believe I was able to inspect the interrupt vector table of the boot-loader firmware. Starting from address 0x1FFF0000 I was looking at the stored data and there is a lot of 0x1FFF3EF0 occurrences. I believe this to be the default interrupt handler. I was able to set break-point to that address.

From address 0x1FFF3EF0 the handler branches to 0x1FFF0A3C where AIRCR is written with 0x05FA0004, which should set the SYSRESETREQ bit and reset the system.

So it seems to me the default behaviour for the boot-loader is to reset the system if unexpected interrupt occurs.

2) If the boot-loader is called before initialisation functions, PA0 has no function

4) PA0 behaviour is disabled by writing all ISER bits 1. This results in proper handover with interrupts disabled.

5) PA2 doesn't have the same effect as it is reconfigured by the boot-loader firmware with pull-up (PA2 is also active high)

So it seams to me the conclusion is, the boot-loader can be exited by leaving external interrupt (on unused pin) configured. However as you have mentioned before it is highly unreliable as STM might change this behaviour in the future.