Nucleo project hung in system memory

[RHerm.3]

Using STM32CubeIde 1.6.0.

Using ST-LINK on NUCLEO-l4r5zi for debug.

1. Create a new project selecting NUCLEO-l4r5zi board.
2. Build with default settings - able to debug and step through main().
3. Add printf("Entering while loop\n") just before final while(1) loop in main. During USB initialization ends up looping in system memory during HAL_Delay(50u) call in USB_SetCurrentMode(). System is locked up.
4. Comment out HAL_Delay call. printf outputs "Entering " then ends up in system memory.
5. Tried increasing Min_Stack and Min_Heap to 128K, does not make a difference.
6. Redirecting STDOUT with int __io_putchar(int ch) does not cause the problem, just adding printf.

Any suggestions for fixes or how to debug this?

[RHerm.3]

Additional information - the attache ZIP file contains a STM32CubeIdo project that demonstrates my problem on a NUCLEO-L4R5ZI board.

When GOOD_CODE is defined in main.c the program runs normally with output redirected to LP1UART (vcom on NUCLEO ST-Link).

When GOOD_CODE is not defined then program locks up during USB initialization at system memory address 0x1fff6d2. No output on serial port.

I have not been able to determine how it gets there.

Any suggestions for tracking this down?

[RHerm.3]

Problem solved.

For some reason the bad code was causing the 0x0 address region to be remapped to system memory.

This results in the vector table being mapped to the ROM boot loader vector table and the first systick interrupt goes off to system memory forever.

The NUCLEO brd has BOOT0 pin pulled down through 10K; should always map 0x0 to FLASH unless FLASH is erased.

I fixed the issue by changing the option bits to ignore BOOT0 pin and always boot from FLASH.

This is a work-around, but it lets me move forward,

I check the L4R5 errata and didn't see anything regarding this.

I would still like a real explanation for why this was happening.