Mpsl init hard fault

RE: Mpsl init hard fault

dejans — Thu, 21 Apr 2022 12:42:27 GMT

Hi,

In general, it is hard to say what is wrong just by looking at the assert.
If you would need more assistance, you should provide the steps to reproduce the issue that you reported.

Best regards,
Dejan

RE: Mpsl init hard fault

dejans — Thu, 21 Apr 2022 09:27:47 GMT

Hi,

Log suggests an error with interrupt handling. You might have a problem with stack overflow or zero latency. You can read more about zero latency IRQ from the Zephyr documentation. There was an issue reported with zero latency interrupt conflicts.

Best regards,
Dejan

RE: Mpsl init hard fault

thiago_hd — Tue, 12 Apr 2022 15:48:48 GMT

Hi again dejans,

I will do that.

In the meanwhile, could you provide some insight on the log output, and how can I interpret it?

Thanks once more.

RE: Mpsl init hard fault

dejans — Tue, 12 Apr 2022 13:49:35 GMT

Hi,

Thank you for providing additional information.
Stop of the logging might be related to the logging buffer size.

[quote user="thiago_hd"]The problem also didn't seem to happen in versions below 1.9.1 of the SDK.[/quote]

Could you please test how your firmware behaves with NCS versions 1.7.0 and 1.8.0 and 1.9.0?

Best regards,
Dejan

RE: Mpsl init hard fault

thiago_hd — Mon, 11 Apr 2022 15:57:08 GMT

Hello dejans,

I am using RTT through VSCode by clicking the button "Connect to RTT in nRF Terminal" in the nRF Connect SDK extension. I was using JLinkRTTViewer as well, the problem happened similarly. The problem happens even if I don't have the logger on, and no monitor hardware connected to the board.

I don't use directly GDB server for anything. After some time struggling with the freezed board I just noted that, after the firmware freezed, if I opened GDB Server and then closed it, the log with the hard fault appeared... After the firmware freezes, the RTT logs stopped showing, the only way the hard fault log appears is if I do that trick using GDB Server. Everything was freezed, the board didn't even rebooted through watchdog. I believe maybe the board didn't rebooted because I don't have edited anything in the HardFault handler.

Resuming, the log was freezed, the firmware wasn't running anymore, and then the hard fault log appeared after opening and closing the gdb server.

The log stopped at approximately 15 hours of timestamp. One hour later I went to see how it was going and there were no more logs. Then, doing the GDB Server trick, the hard fault log showed up.

I am only using VSCode for flashing and monitoring the RTT log.

I cannot use UART log right now because I don't have such serial connections in my custom board, do you think the problem is related to using RTT logs?

The problem also didn't seem to happen in versions below 1.9.1 of the SDK.

Maybe it has something to do with the scanning handler and other interrupts in the firmware (such as LoRa interrupts from Zephyr's driver, or UART interrupts)?

The firmware implements 2 other tasks other than the ble task I described before:

LoRa task and GPS task.

The LoRa task uses Zephyr's driver to receive and send data around.

And the GPS task uses UART interrupts to put chars from the GPS module inside a buffer, then the buffer is processed in the main loop of the task.

Edit: for RTT logging I use LOG_INF, LOG_ERR... there are some logs from Zephyr OS which are using printk. I have some printf statements too in the code but they are disabled through pre-processor.

RE: Mpsl init hard fault

dejans — Mon, 11 Apr 2022 11:46:09 GMT

Hi,

Could you try closing gdb server and gdb before starting logging via RTT?

How do you print the output of RTT log?

What happens if you use UART instead of RTT for logging? Do you experience similar problem?

Best regards,
Dejan

RE: Mpsl init hard fault

thiago_hd — Sat, 09 Apr 2022 20:02:37 GMT

I see that the task which was running was the ble task I have created. So describing a little bit of this task:

In the bluetooth task, I am capturing the BLE advertisers' information inside the scanning handler, when the filter matches the device's name, and adding the captured data to a FIFO using k_fifo_put.

Inside the bluetooth task loop I get the data added to the FIFO by calling k_fifo_get.