nrf51822 Softdevice crash on SDK12.3

RE: nrf51822 Softdevice crash on SDK12.3

Einar Thorsrud — Thu, 15 Oct 2020 12:57:30 GMT

Hi Ricardo,

[quote user="Ricardo Rodrigues"]Is there a way I could find out what exactly was the issue? In what module or what call was taking longer than it should?[/quote]

The SDK or SoftDevice does not have any specific support for that. It would have to be that you either inspect or profile the application in some way.

[quote user="Ricardo Rodrigues"]Also, have you got the chance to look at point 4. from the original post?[/quote]

Well. First of all it does not matter how much additional memory you have. As long as you are able to fit everything you are good. The exception is if you have a too small stack, and starts writing to RAM below the stack (stack overflow). I do not see anything in your question that indicate that this is a problem, though. Do you have any reason to think that this is a problem?

If you want to free memory, you need to look at what you use. Removing something from flash_placement.xml does not help, as that just tells the linker where to put things. If you remove something that is unused, then it makes no difference. If you remove something that is used, then you will get a linker error.

Einar

RE: nrf51822 Softdevice crash on SDK12.3

Ricardo Rodrigues — Thu, 15 Oct 2020 12:33:43 GMT

Hi Einar,

Yes, I am using "s130_nrf51_2.0.1_softdevice.hex".

I am using timers, app_scheduler library, and APP_UART_FIFO_INIT(), which calls a callback in an interreupt.

The app_sched_event_put() function has a critical region, but it should be fast executing.

Since yesterday I have:

- made some optimizations to reduce memory usage to free up RAM for having another timer;

- split the initial timer's tasks into two different timers, executing at different intervals;

- moved some of the app_scheduler tasks to the new timer, because maybe I was scheduling too many tasks two quickly;

- and reduced the number of events overall;

The nrf app looks like it is now running more stable, so maybe it was just what you said. Some longer execution of some task.

But this still leaves me wondering what exactly was the case and not knowing for sure if I fixed it or just reduced the frequency of the crashes (which is already a good thing, of course - but a better understanding of the problem would be even nicer).

Is there a way I could find out what exactly was the issue? In what module or what call was taking longer than it should?

Also, have you got the chance to look at point 4. from the original post?

Best regards,

Ricardo

RE: nrf51822 Softdevice crash on SDK12.3

Einar Thorsrud — Thu, 15 Oct 2020 12:14:57 GMT

Hi Ricardo,

I assume you are suing S130 2.0.1? If so, the assert you get at 0x0000f764 indicate an assert caused by the SoftDevice missing a BLE event. Do you use the timeslot API? Or have long high priority interrupt routines, or critical sections?

Einar