[STM32N6] UART+GPDMA (Adafruit BNO085) works in FSBL but hangs in Application. Breakpoint fixes the bug.

[damole]

Hello ST Community,

I am facing this issue developing firmware on the NUCLEO-N657X0-Q (STM32N657).
My architecture involves a standard FSBL that jumps to a main Application.

Application:
Interfacing with a Adafruit BNO085 IMU via UART (3 Mbps) using the CEVA SH2 driver, adapting the official CEVA SH2 example code of this repository to my Nucleo. The driver uses USART2 with GPDMA1 Channel 0* (Circular Buffer for RX).
Setup Details:

MCU: STM32N657X0

Peripheral: USART2 (3 Mbps) + GPDMA1 Channel 0 (RX Circular Buffer).

Timer: TIM2 (used for microsecond timestamping in the driver).

Cache: Disabled (to rule out coherency issues).

Symptoms:

1. FSBL: If I initialize and run the sensor logic inside the FSBL, it works perfectly.
2. Application: If I move the exact same logic to the Application (after the jump), the code hangs inside the driver's code.
3. Breakpoint fixes the problem: In the Application, if I place a breakpoint at the beginning of the shtp_service() function (called periodically), hit it once, and then resume execution, everything starts working perfectly.
4. Free Run: If I run the Application without the debugger (or without hitting the breakpoint), it hangs immediately during the sensor initialization handshake.

Hang Point:
The code gets stuck in the while loop here (in sh2.c:(

static int opProcess(sh2_t *pSh2, const sh2_Op_t *pOp)
{
int status = SH2_OK;
uint32_t start_us = 0;

start_us = pSh2->pHal->getTimeUs(pSh2->pHal);

status = opStart(pSh2, pOp);
if (status != SH2_OK) {
return status;
}

uint32_t now_us = start_us;
// While op not complete and not timed out.
while ((pSh2->pOp != 0) &&
((pOp->timeout_us == 0) ||
((now_us-start_us) < pOp->timeout_us))) {

if (pSh2->pShtp == 0) {
// Was SH2 interface closed unexpectedly?
pSh2->opStatus = SH2_ERR;
break;
}

// Service SHTP to poll the device.
shtp_service(pSh2->pShtp);

// Update the time
now_us = pSh2->pHal->getTimeUs(pSh2->pHal);
}

if (pSh2->pOp != 0) {
// Operation has timed out. Clean up.
pSh2->pOp = 0;
pSh2->opStatus = SH2_ERR_TIMEOUT;
}

return pSh2->opStatus;
}

I have already verified and tried (ALL FAILED):

Clock/Timers:
* Called `SystemCoreClockUpdate()` at App start (verified Clock variables are correct).
* Verified `TIM2` (used for timestamps) is enabled and counting.

Interrupts and Context:
* `__disable_irq()` used before jumping from FSBL.
* `MX_...Init` functions are called before `__enable_irq()` in the App.
* USART2 and GPDMA1 interrupts are correctly mapped in `stm32n6xx_it.c`.

Cache:
* D-Cache is Disabled.

* "Magic Breakpoint":
* I suspected an Overrun Error caused by the sensor sending data during the jump-to-application, which the debugger might clear by reading registers.
* Attempt: I added manual code to clear ORE, NE, FE flags and flush the RDR register specifically before initializing the driver in the App.
* Result: It DID NOT help. The code still hangs in free run.
* Attempt: Added HAL_Delay(10) or HAL_Delay(100) inside the waiting loop to simulate the pause.
* Result: It DID NOT help.

Configuration Details:

* CubeMX: USART2 and GPDMA1 Channel 0 are assigned to the "Appli" Context.
* Driver: HAL_UART_Receive_DMA for RX, HAL_UART_Transmit_IT for TX.

My Questions:
Since manual flag clearing and delays don't fix it, but a debugger pause does:

1. Is there a specific GPDMA Reset/De-init procedure required in the FSBL or at the start of the Application for the STM32N6?
2. Could this be related to the RIF (Resource Isolation Framework)?
3. Why does the "Magic Breakpoint" fix the issue when HAL_Delay and manual Flag Clearing do not? Does the debugger perform a specific bus access or clock enablement that I am missing?

I am stuck on this and any insight on the STM32N6 transition from Bootloader to App regarding UART/DMA (or whatever the issue is related to) would be appreciated.

I attach the code for the (working) FSBL-only project and the project with the FSBL+Appli that has the issue. Both projects are CMake projects for VSCode.

Thanks.

[Saket_Om]

Hello @damole 

Could you configure the UART and DMA interrupt priorities in the FSBL+Application project to match exactly those used in the working FSBL‑only project, and try again?

[damole]

Hello @Saket_Om

Thanks for the reply. I already tried this, and I tried again now just to be sure. Setting the same priorities as in the FSBL-only project does not solve the problem, the behavior remain the same as described above.

[damole]

@Saket_Om do you have any more hints? I am really stuck and some help would be really appreaciated.
Thanks