Intermittent Break at address "0x1fff51f4" with no debug...

[DerekR]

Hardware:

MCU: STM32L4R9ZGJ6 (Custom board)

OSPI mapped to address 0x90000000

ST-Link V2

PH3-BOOT0 pin pulled to ground with 10k Ohm resistor.

Software:

IDE: STM32CubeIDE 1.6.0 (Build: 9614_20210223_1703 (UTC)

SDK: STM32Cube_FW_L4_V1.14.0

TouchGFX assets are loaded in OSPI at address 0x90000000 (Probably not relevant to my issue)

STM MCU Option Bytes Configuration in STM32CubeProgrammer:

nBOOT1: Checked

nSWBOOT0: Checked

nBOOT0: Checked

Issue:

Hello,

My issue is that when attempting to debug the MCU in STM32CubeIDE, it often attempts to start at address 0x1fff51F4 with the message "Break at address "0x1fff51f4" with no debug information available, or outside program code". main() is never called because my breakpoint at the top of main() is never hit. To mitigate the issue, I simply press the red "Terminate" button to stop the debug session, then press the "Debug" button to restart, and the program then loads at the correct address and breaks in main(). This happens randomly without any changes to the code, option bytes, or hardware. Yesterday it was happening about 50% of the time, now it's about 10% of the time and seems to change in frequency. I wouldn't mind stopping and restarting the debugger to mitigate, but CubeIDE take roughly 3 minutes to program and connect the debugger so stopping and restarting is time consuming.

Question 1: What could be causing this strange behavior of STM32CubeIDE jumping to address 0x1fff51f4?

Question 2: Does STM32CubeIDE not load the PC (Program Counter) with the application start address and jump to that? Or does it still look at the option bytes / BOOT0 pin to determine start address?

Thanks!

Derek

[NArnd]

Hi,

It might be unrelated but I have just alerted ST to this fact about the tool support for L4+:

The USART1->PRESC and PWR->CR5 registers are missing from the debug SFRs view in CubeIDE 1.7.0.

// Missing TIM_BDTR bit defines in stm32l4r7xx.h:

#define APPL_TIM_BDTR_BKDSRM_Pos                (26U)

#define APPL_TIM_BDTR_BKDSRM_Msk                (0x1UL << APPL_TIM_BDTR_BKDSRM_Pos)

#define APPL_TIM_BDTR_BKDSRM                    APPL_TIM_BDTR_BKDSRM_Msk

#define APPL_TIM_BDTR_BK2DSRM_Pos               (27U)

#define APPL_TIM_BDTR_BK2DSRM_Msk               (0x1UL << APPL_TIM_BDTR_BK2DSRM_Pos)

#define APPL_TIM_BDTR_BK2DSRM                   APPL_TIM_BDTR_BK2DSRM_Msk

#define APPL_TIM_BDTR_BKBID_Pos                 (28U)

#define APPL_TIM_BDTR_BKBID_Msk                 (0x1UL << APPL_TIM_BDTR_BKBID_Pos)

#define APPL_TIM_BDTR_BKBID                     APPL_TIM_BDTR_BKBID_Msk

#define APPL_TIM_BDTR_BK2BID_Pos                (29U)

#define APPL_TIM_BDTR_BK2BID_Msk                (0x1UL << APPL_TIM_BDTR_BK2BID_Pos)

#define APPL_TIM_BDTR_BK2BID                    APPL_TIM_BDTR_BK2BID_Msk

Comparing RM0351 (L4) and RM0432 (L4+), it's clear that both the two registers PWR->CR5 and USART1->PRESC and the four TIM->BDTR bits are additions that only exist in L4+. One such omission could be attributed to human error, but several errors suggests a systematic problem. I suspect that the tool support for L4+ was a sloppy copy of L4 and that there might be a few use cases where an L4+ effectively running on L4 tool support could malfunction.

I fear that ST needs to revise the tool support for L4+, with focus on differences compared to L4.

/Niclas

[NArnd]

Sorry that this is getting off-topic from the original debugging problem, but I just reported one more error for L4+. Who knows how many errors there are in the tool support for L4+?

RM0432 Rev 9 50.7.5 does not reflect L4+. It seems to be copied from RM0351 (L4).

First, it doesn't mention USARTx->PRESC and second, it doesn't mention the correction factor that this formula (define) from stm32l4xx_hal_uart.h incorporates:

#define UART_DIV_SAMPLING16(__PCLK__, __BAUD__, __CLOCKPRESCALER__)                      \

 ((((__PCLK__)/UARTPrescTable[(__CLOCKPRESCALER__)]) + ((__BAUD__)/2U)) / (__BAUD__))

Is it even correct to add __BAUD__/2 in the above formula?

/Niclas

[NArnd]

It turns out that __BAUD__/2 is a failed attempt at rounding up the result. I have proven to ST's support that this formula suffers from rounding errors, but they won't correct it even though I have provided a code sample that works:

uint32_t brr = (uart_clk << 1U) / (prescaler * baud_rate);

if ((brr & 0x1U) != 0U)

{

 brr++;

}

USARTx->BRR = brr >> 1U;

Please verify this by using the following parameters:

uart_clock = 23

prescaler = 3

baud_rate = 5

As I just said, who knows how many errors there are in the tool support for L4+?