High RAM Application Questions

[Dave_couling]

According to the *.map file the .bss (RAM) usage for my Application is 0x16b8 or 5816 bytes. This is obviously a very high RAM Application, likely due to the abundance of app_timers I use. I am using SDK6.1 and SD7.1. I want to make sure I'm not going to run into RAM issues at RUN-TIME. With this RAM spec in the .map file do I need to modify the gcc_startup_nrf51.s ? Or modify any other files to account for this RAM usage? Any other considerations I should be mindful of? Thank you for your advisement Nordic.

-DC

[Dave_couling]

We have seen (seemly at random) when I go to press the button, the chip seems to grind to a halt. This can happen at any point. Within 2hrs of programming or +3weeks. I had suspected that something to do with the app_button module was causing this. Since the Button Module uses the scheduler, along with App_timers and SoftDevice. Could these 3 items all using the Scheduler at the same time potentially cause a CPU freeze?

I have recently bumped up the SCHED_QUEUE_SIZE to 30 (from 18). Is there a rule of thumb for setting this? We have 20 app_timers, 2 other misc app_sched_event_put handlers, app_button and the SoftDevice. Thanks for the help.

[RK]

CPUs don't freeze, they get in loops, they go to fault handlers when they detect error conditions, and they are very good at finding seemingly impossible race conditions, but they don't just stop working. Your CPU is running and it's doing something even though your board is unresponsive. What does your hardfault handler do, just loop, how about your app error handler, does it turn on some LEDs or raise a GPIO line you can check externally? When the device becomes unresponsive can you get a debugger attached to it and find out where it is?

[Dave_couling]

You absolutely correct, I was speaking in terms of external perception. When this happens a GPIO does raise (red LED turns on). Upon on the next button push the device restarts.

We can't get this to occur on the bench, have only seen it in field tests with release firmware.

[RK]

One of those hard debugging situations, it only breaks when you're not looking. What errors cause the LED to turn on and the next push to reset? APP_ERROR_CHECK(), hardfault, all of the above? That might help fractionally to narrow it down, but you probably have lots of app error checks so it may not.

You can run release firmware on a board and still get a debugger on it when it fails. That at least gives you a stack trace and there's enough information in the original binary file to figure out where you were, especially if you've built release code (ie optimized) with debug info.

You need some kind of post-mortem when the thing fails, somehow, it's the only way.

[Dave_couling]

Unforuntely we cannot get stack traces as there is a power-cycle uponing access the SWD pins. I believe the issue may again be related to the Scheduler. We use BLE event to trigger scheduler events. These events start app_timers. It is likely a condition where several BLE events (Stack uses the scheduler as well) causing several scheduler events which somehow fills up the Scheduler Queue and then odd things happen. I don't really know how to design around this. I cannot increase the Scheduler Queue anymore without RAM overflows.

When using app_timers with the scheduler, do app_timer_start and app_timer_stop use the scheduler as well? or just the timeout_handler? Trying to track down how I could be filling up the queue.

Thanks for the help guys.

-DC