Inconsistent vector table on Nucleo with STM32L4R5

[Kemaguco]

I have a project, created with STMCubeIDE 1.6.1, for a Nucleo STM32L4R5 board. I experience issues with the vector table not being always the correct one, depending on some influence I'm not quite sure about. Let me explain.

The project has a few peripherals and FreeRTOS enabled. I used the default generated main.c and added some calls in the default task function. In no way or shape did I edit the generated code (HAL, etc), apart from adding some functions to the previously mentioned default task function. When adding too 'much' code (I think this is the trigger), and programming the device with STMCubeIDE (i.e. debug/run), the device would get stuck in HAL_Init() when the HAL tick timer interrupt would fire. I found out that the vector table was populated with pointers to system memory (0x1fffxxxx), causing the MCU to get stuck in an infinite loop there. It should be noted that the vector table in the binary/map compilation output was absolutely correct w.r.t. the IRQ function pointers, they weren't pointing to system memory and were in fact pointing to the entries of the IRQ functions I expected.

If I commented out a bit of my code in the default task function, it suddenly would work again. The vector table would get populated with the expected IRQ function pointers and the MCU wouldn't hang in HAL_Init() anymore. This was confirmed by reading out the vector table located at address 0x0 with the ST-link debugger on the board.

Furthermore, if I used a binary that would get stuck, I noticed that upon disconnecting and reconnecting the ST-link USB cable and providing a hard reset (Nucleo reset button), the MCU wouldn't get stuck (as indicated by the UART output in the default task and the led blinking task).

Last thing I noticed was, contrary to other Nucleo boards I have, if I power up the Nucleo board with the STM32L4R5, the MCU will not start executing its program until I hit the reset button.

I'm not sure why it is doing what I'm seeing. It prevents me from using the debugger, so I'd like to find a sollution to this incorrect vector table issue, so I can debug again. I sadly lack a second L4R5 Nucleo board to exclude the possiblity of a defective board. Couldn't really find other questions that had the same problem, or if I did find something that was similar (i.e. getting stuck in HAL_init/system memory), they lacked tracing it back to the vector table.

So in short: has anybody experienced the vector table getting 'corrupted' (probably just plain wrong one) when using the debugger/st-link and how to resolve it? Output binary/map file was, everything seems fine. Post disconnect and hard reset it doesn't get stuck anymore.

[SBEN .2]

Hello @Kemaguco​ ,

What is your boot configuration? Check if it is well configured to run from flash.

 

Best regards,

@SBEN .2​ 

[Kemaguco]

Hello @SBEN .2​ ,

Thanks for your rapid response.

I just double checked the option bytes with the ST Link utility:

nBoot0_SW_Cfg is checked in the ST Link utility, and the tooltip tells me that if it is checked, BOOT0 is bonded to the PH3/BOOT0 GPIO, therefor the system is not using the BOOT0 user option bit but the BOOT0 pin (i.e. nSWBOOT0 is set in FLASH_OPTR).

Since it is a Nucleo board, I checked the schematic to ensure the BOOT0 pin was pulled down. I noticed that SB183 was placed so that the PH3/BOOT0 pin is pulled down to GND with a 10K resistor.

I also double checked if the main flash wasn't empty (as per your table), so I did a read of address 0x08000000 and distinctly observed non empty entries (in fact, the correct vector table was there, as expected).

Perhaps this is relevant, but I noticed that nBFB2 was not being selected in the options bytes. The tooltips tells me that Flash Bank2 would be used in that case. Since flash bank2 starts at 0x0810 0000 instead of the 0x0800 0000 the output of the compiler specifies, I checked nBFB2 in the options bytes and tried again, sadly without any different behavior. I'm also not sure how the device could've booted with nBFB2 unchecked in the first place, since the tooltip implies Bank 2 would've been used and that one was empty. If it has any relevance, DBANK is also selected in the ST Utility.

[Tesla DeLorean]

One of the issues here is the protection mechanisms in newer model STM32, where a power cycle and simple reset are handled differently.

The ROM code checks the integrity of the vector table. Resetting during programming may further complicate the behaviour.

You could perhaps​ add code in Reset_Handler to set the SCB->VTOR value correctly and change the SYSCFG mapping to FLASH.

[Kemaguco]

For the moment I seem to have a little bit of success with setting the SYSCFG to FLASH. The issue is still far from solved, but at the very least I can debug again. A 'run' configuration in STMCubeIDE (program with the ST-link & run) still results in getting stuck issues, but due to how the 'debug' configuration works in STMCubeIDE, the MCU ends up with the SYSCFG being set to flash and can thus function. It was immediately obvious that SYSCFG wasn't configured correctly. When using a 'bad' binary, SYSCFG was set to system memory (0x1) if left unaltered.

Whilst I am very grateful for your pointers, which helped me a great deal to at the very least get back to debugging again, I'm still a bit stuck. Whilst I can work around the issue when debugging, the other issue of the MCU not properly booting after power-up without a hard reset still lingers. I feel these issues are related, but at this point I'm a bit lost at finding the right angle for this problem.

[Tesla DeLorean]

I'm in a difficult situation here, I have my own L4R5ZI board and using Keil, and not struggling with these issues.

Might want to disconnect the ST-LINK SWDIO, SWCLK, and NRST so you can check the reset performance independently.

I suspect the state of the Option Bytes is at play here. You should get some working settings, and then avoid changing/writing them repeatedly.

[Seegras]

It seems I had a similar issue as you with the same board.

See here: https://community.st.com/s/question/0D53W00000yYDjPSAW/if-octospi-is-enabled-system-memory-is-mapped-at-0x00-after-reset-even-thought-flash-should-be-mapped

I reflashed the on-board debugger with the SEGGER J-Link FW and the issue seems resolved. (https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/)

Maybe this helps you a bit.