This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

High RAM Application Questions

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

  • That's odd - I can connect to running boards without a power cycle, it connects then I can halt. I'll try one over battery power later and check it's true in that case as well. There are other options for getting debug info later but they require manually erasing a flash page, dumping the registers and the contents of the stack page, you can try that, it's 30-40 lines of assembler. Then you pull the data off and laboriously cull through it.

    So you think that it's the scheduler queue filling up. What do you do if app_sched_event_put() returns NRF_ERROR_NO_MEM? Do you use APP_ERR_CHECK() on it and go to the error handler? can you drop events if you can't queue them, can you at least make it light a different LED so you know this is the case?

    A quick look at the code for app_timer says it only calls the scheduler on timeout events.

  • Hi RK,

    Currently I ignore the error NRF_ERROR_NO_MEM and move-on, effectively skipping the event_put. I currently don't drop events. I'll have to look more closely at this. Perhaps there is something there.

    I'm more concerned that an app_timer timeout handler cannot execute due to the FULL queue. This is a condition I can't trap.

  • I think I may have found the issue. Perhaps some insight from Nordic could help. My application uses the app_button module which internally uses the GPIOTE for timing. I also use GPIOTE for PWM generation. I just noticed that my application had APP_GPIOTE_MAX_USERS 2

    I believe that under a specific race condition a button push and buzzer tone attempting to generate at the same time may have caused the odd Lock-up issue. If I think I may have found the issue. Perhaps some insight from Nordic could help. My application uses the app_button module which internally uses the GPIOTE for timing. I also use GPIOTE for PWM generation. I just noticed that my application had APP_GPIOTE_MAX_USERS 2

    I believe that under a specific race condition a button push and buzzer tone attempting to generate at the same time may have caused the odd Lock-up issue. Does this sound legit?

Related