What is the cause of CAFEBABE?

[hiroiwas]

Hello.

In the BLE software under development, the device uses nRF52840 and uses s140 v7.3.0.

Currently, although I have identified the location where the problem occurs, I am still suffering from an exception for which I do not know the reason.

In the software, BLE+UARTE (over serialization) works together.

When the following code is executed in the main loop by receiving commands via UART, an exception will occur with a high probability if BLE is operating.

This is the call stack trace when ASSERT occurs.
The error occurred because the main loop stopped due to an Exception after GetMissingIndex, and it was no longer possible to receive data from the UART.

And, a stack dump of the call stack.

I think that the reason why CAFEBABE appears in the stack at the time of exception is due to SoftDevice.

Do you know anything about the cause of this Exception?

Previously, when I changed the SoC from nRF52832 to nRF52840, I thought I had missed the fix by changing SoftDevice from S132 to S140, but there was no problem with ses_startup_nrf52.s and ses_startup_nrf52840.s.

Refer to UART Interrupt fault.

Best regards.

[Vidar Berg]

Hello,

I don’t see any fault exceptions in the call stack you posted, but I see that the app_error_handler appears to be invoked from your phy_events_handler() function. Have you checked which assert failed?

Do you know anything about the cause of this Exception?

Is it the UART interrupt/exception you are refering to?

Best regards,

Vidar

[hiroiwas]

Hello Vidar.

What I want to inquire about is not the UART interrupt.

The ASSERT that occurs within the phy_event_handler() function occurs because UART reception cannot be received within the main loop.

As a question, I would like to know why an exception occurs in the nrf_atflags_get search loop in AppDFU_GetMissingIndex() function in the main loop.

In this exception, PC=FFFFFFF8, which is an impossible value.

If you look at the stack dump of this exception, it will be CAFEBABE FFFFFFF9, so can you see the SoftDevice exception handling from here?

Best regards.

[Vidar Berg]

Hello,

Is the question why the UART interrupt is triggered in the first place? The Softdevice is only forwarding the UART interrupt to the application.  I'm not able to explain the EXC_RETURN value. Are you debugging with IAR?

Best regards,

Vidar

[hiroiwas]

Hello Vidar.

> I'm not able to explain the EXC_RETURN value.
From the call stack trace, I thought that the main loop stopped due to some kind of invalid exception, and the subsequent UART interrupt led to the ASSERT, but I understood that you did not have the information to solve the problem.

I will also look deeper into this, including the UART interrupt side.

Best regards.

[Vidar Berg]

I believe the exception frame is for the UART IRQ. If there was another expcetion with stack corruption, I would have expected it to result in a fault exception.