MCU Stops Responding

RE: MCU Stops Responding

Edvin — Thu, 21 Jul 2022 13:29:50 GMT

Hello,

Sorry, I was out of office, and I will be next week as well. Unfortunately, due to limited staffing during the summer, I am not certain my colleagues will have the time to look into unhandled "old" cases like this one.

[quote user="bryanhsieh"]Therefore the CPU is not stuck in a while loop, it crashes after the Serialize_SPI(CMD,1+size,NULL,0,true) function, which is what is confusing[/quote]

This is not our function. What does it do? Did you try debugging it to see what's going on? Are there places inside (or after, I didn't understand where you meant) that the application can be stuck?

Best regards,

Edvin

RE: MCU Stops Responding

bryanhsieh — Fri, 15 Jul 2022 18:02:46 GMT

Thanks. But unfortunately the problem is unrelated to it, as like you said the size is always +1. Also _M_DRV_MC36XX_REG_WRITE function ( where the program would fail after ) is always writing 1 as the size however despite that the MCU would freeze randomly after a few minutes.

RE: MCU Stops Responding

hmolesworth — Thu, 14 Jul 2022 17:01:42 GMT

Using parameter size to define stack allocation and (worse) memcpy() would be flagged as an error by MISRA; if size is ever 0 there will be a crash or something horrible; fix by using predetermined max buffer size (not an issue here due to the +1) or do not perform stuff like memcpy() if size == 0. Possibly not the issue, but worth addressing as often the errors are very random and hard to catch.

RE: MCU Stops Responding

bryanhsieh — Thu, 14 Jul 2022 16:34:31 GMT

To Edvin,

Hi sorry for the late reply.

I thought the problem was resolved but upon testing the device recently, the same CPU locking behaviour occurred again.

The SPI is set up with an event handler and the mcube_write_regs is called from the main loop.

The issue is not interrupt related as the CPU locking occurs only after SPI transfer has finished ie the SPI_done flag has been set to true by the SPI interrupt handler. Therefore the CPU is not stuck in a while loop, it crashes after the Serialize_SPI(CMD,1+size,NULL,0,true) function, which is what is confusing.

RE: MCU Stops Responding

Edvin — Tue, 21 Jun 2022 20:50:37 GMT

Ah, maybe I misunderstood then.

So even if you remove the additional NRF_LOG_FLUSH() you are still stuck somewhere, right? Have you tried debugging and stepping through mcube_write_regs()? Where does it stop?

Is your SPI set up with an event handler or without? And in what context is mcube_write_regs() called? Is it from inside an interrupt, or from main() (in the main()'s while loop?)

I suspect that you are facing an interrupt priority blocking issue.

Best regards,

Edvin

RE: MCU Stops Responding

bryanhsieh — Tue, 21 Jun 2022 14:29:42 GMT

Hi Edvin,

Thanks for the prompt response. I do not think the error is related to the log process as they were added

after I noticed the MCU would stop advertising randomly. But thanks for the best practice when it comes to logging.

RE: MCU Stops Responding

Edvin — Tue, 21 Jun 2022 13:51:41 GMT

I tried to figure out where it says that you shouldn't call NRF_LOG_PROCESS() from elsewhere (NRF_LOG_FLUSH() is just a repeated call to NRF_LOG_PROCESS()), but I only found this in nrf_log_ctrl.h:

/**@brief Macro for processing a single log entry from a queue of deferred logs.
 *
 * You can call this macro from the main context or from the error handler to process
 * log entries one by one.
 *
 * @note If logs are not deferred, this call has no use and is defined as 'false'.
 *
 * @retval true    There are more logs to process in the buffer.
 * @retval false   No more logs in the buffer.
 */
#define NRF_LOG_PROCESS()    NRF_LOG_INTERNAL_PROCESS()

RE: MCU Stops Responding

Edvin — Tue, 21 Jun 2022 13:49:09 GMT

Hello Bryan,

I see that you have added NRF_LOG_FLUSH() inside M_DRV_MC36XX_HandleINT().

I don't know where your first snippet is from (an interrupt or the main() loop), but you should never add NRF_LOG_FLUSH() or NRF_LOG_PROCESS() anywhere unless you mean to shut down immediately after. It should only be used in the main() loop and in error handlers. The reason for this is that this is not what we call a thread safe / thread aware function. What could happen (and is probably happening) in your case is that NRF_LOG_FLUSH() or NRF_LOG_PROCESS() is called regularly from your main loop (either directly, or indirectly from a function called something like "idle_state_handle()". Then, if you get an interrupt, and this NRF_LOG_PROCESS() execution is interrupted half way through, and then you call NRF_LOG_PROCESS() again from that interrupt, then your nRF52832 will crash, which is probably what you are seeing.

If you are having problems with too much log for the log module to handle (which I guess is the reason you added NRF_LOG_FLUSH() to another location), I suggest you either increase the log buffer size, or turn off deferred logging (both of these are done from sdk_config.h. Look for NRF_LOG_BUFSIZE and NRF_LOG_DEFERRED).

Best regards,

Edvin