Nucleo-L4R5 is kept in reset after downloading sketch

[PerennialNovice]

Hi,

I am experimenting with Nucleo-L4R5 and try to run the CheckVariant example sketch on it.
This sometime succeedes, but most of the time the µC gets stuck in Reset. The red LED is on. When trying to program it with STM32CubeProgramer I get the error "The core is kept under Reset!"
Doing a full chip erase and several resets is able to bring the µC back to normal operation but this just keeps happening very often.
I also tried downloading a simple "blink" example, same result.
When connecting the stuck board to STM32CubeProgrammer, fault analysis is executed and I get the message that DIV_0_TRP bit was enabled.
I suspect this is an error with stm32duino, not with the µC itself, thats why I am writing here.

[PerennialNovice]

Same behaviour on Windows and Linux (Xubuntu in VM)

[fpistm]

Hi @Pestimist
in fact this is not linked to the core.
Issue is under investigation internally as it has been reproduced using application generated thanks STM32CubeIDE.
It has been found with SWAN R5 board, see #1511
As a workaround you can simply use the mass storage upload method.

[PerennialNovice]

Thank you @fpistm for this information
mass storage upload may help here but is not available for the generic variants (I'm still trying to create the L4P5 variant). Is there a possibility to have it available for generic variants?

[fpistm]

Unfortunately not it is too specific to be added to generic upload method.

[PerennialNovice]

too bad
can I make use of the fix you proposed? How could I do that?

[fpistm]

Well you can locally change the GenL4 upload line to add: -ob nBOOT0=0 -ob nBOOT0=1

Arduino_Core_STM32/boards.txt

Line 5089 in 6479b8a

GenL4.menu.upload_method.swdMethod.upload.options=-g

I did not add it as issue seems linked to STM32L4+ and do not want impact all the STM32L4.

[PerennialNovice]

Thank you very much

[PerennialNovice]

After successfully downloading the CheckVariant sketch via SWD the µC started to behave very erratically.

First it was unreacheable, found out that Flash protection registers were changed.
Managed to get them back to normal and program the chip anew.
But the registers keep getting messed up on nearly every programming.
And the chip keeps resetting, output on terminal is as follows:

#####
NUM_DIGITAL_PINS#####
NUM_DIGITAL_PINS#####
NUM_DIGITAL_PINS#####
NUM_DIGITAL_PINS#####
NUM_DIGITAL_PINS#####
NUM_DIGITAL_PINS#####
NUM_DIGITAL_PINS#####
NUM_DIGITAL_PINS#####
NUM_DIGITAL_PINS#####
NUM_DIGITAL_PINS#####
NUM_DIGITAL_PINS#####

This happens regardless how I program the chip (Arduino IDE, Sloeber, STM32programmer, mass storage, SWD)
Even writing registers and resetting the core within STM32Cube Programmer yields the wrong entries in the registers.
seems like the chip itself is broken?

[fpistm]

Yes very strange.
Anyway, what do you want achieve? Nucleo L4R5 is already available in the core?

[PerennialNovice]

I wanted to add the L4P5 variant, did all the steps mentioned here but had no serial output after programming the CheckVariant sketch.
So I tried the sketch wit the L4R5 variant just to make sure all the rest of my setup is working fine.
That is how I ran into all these issues.

[fpistm]

So you tried to add the generic L4P5. If Serial does not work probably that generic SystemCoreConfig is not correct or ldscript as this is what is missing (and off course boards.txt entry addition)

[PerennialNovice]

Yes, but now I also want to get the Nucleo-L4R5 back working, if that is possible.
And I really would like to know what is wrong with it and how I can possibly have caused that.
I don't want to brake another board...

[fpistm]

Well, hard to tell what is wrong. You can try to use the STM32CubeProgrammer and check options bytes.
Also update the STLink Firmware of your board if needed.

[PerennialNovice]

ST-Link firmware update did not change anything.
To be honest I don't really know much about the option bytes, and there are many :)
Anything special you consider worth looking at?
Thanks for your support!

[fpistm]

You can share a screenshot of your OB then I will compare to mine.

[PerennialNovice]

[PerennialNovice]

This seems to be when all works fine, trying to recreate the "not working" state

[PerennialNovice]

side question:
is there a difference between Windows and Linux versions of Arduino IDE and STM32duino considering this issue?
I'm asking because build on Linux is way faster even when running out of a VM...
would save me some time

[PerennialNovice]

OB are the same when the MCU doesn't start and the red LED on the Nucleo board is lit

[fpistm]

I've the same. Issue come from Arduino IDE on Windows. Core is only source file.
On windows you can try to disable your antivirus.

This seems to be when all works fine, trying to recreate the "not working" state

I thought your board does not work anymore ?

[PerennialNovice]

it is complicated...
I don't know why, but sometimes i can download a sketch (or bin via CubeProgrammer) and the code gets executed. Sometimes the red LED is on and the board seems to do nothing
still trying to find out what causes these different states, no luck so far :/

[fpistm]

I would checked nBoot0 and nSWBoot0 by default.
About the issue it is similar to the one I've mentioned before and I don't have more clue for you as it is not related to the core and under investigation internally by our experts but it can take long time to have their feedback.

[fpistm]

I moved this thread as a discussion as it is not linked to the core (as I said I've reproduced with a simple blink project with STM32CubeIDE).

[PerennialNovice]

...now I finally understand that with "core" you aer NOT talking about the MCU core, but the stm32duino-core...

With nBOOT0 and nSWBOOT0 checked and BFB2 unchecked it seems to work reliably (I compared OB with the ones from Nucleo-L4P5 I also have)

[fpistm]

Right in Arduino world core is defined like this: https://www.arduino.cc/en/guide/cores
When I talk about the hardware component, I talk about MCU.

[CHAMSTM]

Hello,

I'm not sure if my answer is still useful now, but:
Here the issue is that when you write a binary in the flash and try to execute it, it doesn't execute.
This is normal due to PEMPTY that is cleared only by power off/on reset.

The flash is considered "empty" as long as first word @0x0800 0000 contains 0xFFFFFFFF.
The evaluation of this word is done at device startup (after reset) and PEMPTY is set if condition is true.
If PEMPTY is set, then the boot is forced (by hardware) to the system Bootloader (0x1FFFxxxx)
PEMPTY can be cleared only after a power off/on reset (not after a system reset).

So if you take an empty device, write your binary then reset (using any tool), it will not execute your loaded code. It will execute System Bootloader till next power off/on reset.

You can get rid of this behavior by forcing boot on Flash using Option bytes nBootSW=0, nBoot0=1, nBoot1=1.

I hope it helps.

[PerennialNovice]

I haven't had time to play aournd with the Nucleos lately but every bit of information is always welcome :)
Especially if I learn something new.
thank you very much for sharing your insights :)

[fpistm]

Hello,

I'm not sure if my answer is still useful now, but: Here the issue is that when you write a binary in the flash and try to execute it, it doesn't execute. This is normal due to PEMPTY that is cleared only by power off/on reset.

The flash is considered "empty" as long as first word @0x0800 0000 contains 0xFFFFFFFF. The evaluation of this word is done at device startup (after reset) and PEMPTY is set if condition is true. If PEMPTY is set, then the boot is forced (by hardware) to the system Bootloader (0x1FFFxxxx) PEMPTY can be cleared only after a power off/on reset (not after a system reset).

So if you take an empty device, write your binary then reset (using any tool), it will not execute your loaded code. It will execute System Bootloader till next power off/on reset.

You can get rid of this behavior by forcing boot on Flash using Option bytes nBootSW=0, nBoot0=1, nBoot1=1.

I hope it helps.

Thanks @CHAMSTM for your feedback. Anyway it only explain for the first flash.
Issue here is that for the same Nucleo L4R5 after a first correct programming it works or not. Same issue ss stated in the internal BZ.