• State Not Answered
  • Replies 1 reply
  • Subscribers 73 subscribers
  • Views 459 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 285337
Options
Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

nRF52840 RAM adjustment causes hard lock

Steve.Klinkon

Hi all,

I'm experiencing a weird behaviour when adding NUS BLE profile to a standard BLE Peripheral HRS example. 

The code compiles fine without any error or warning, and it's expected that the RAM starting point should be adjusted once SoftDevice configuration has been changes (e.g. a new BLE service is added). 

During the app run, I use a debugger and RTT logger, and as expected an error appeared asking to change the RAM start address:

<info> app_timer: RTC: initialized.
<debug> nrf_sdh: State request: 0x00000000
<debug> nrf_sdh: Notify observer 0x00046E4C => ready
<debug> nrf_sdh: State change: 0x00000000
<debug> nrf_sdh: State change: 0x00000001
<warning> nrf_sdh_ble: Insufficient RAM allocated for the SoftDevice.
<warning> nrf_sdh_ble: Change the RAM start location from 0x20002BE0 to 0x20002BF0.
<warning> nrf_sdh_ble: Maximum RAM size for application is 0x3D410.

The original unaltered address for <ble_app_hrs_pca10056_s140> is as follows:

FLASH_PH_START=0x0
FLASH_PH_SIZE=0x100000
RAM_PH_START=0x20000000
RAM_PH_SIZE=0x40000
FLASH_START=0x27000
FLASH_SIZE=0xd9000
RAM_START=0x20002be0
RAM_SIZE=0x3d420

Once I changed RAM start address to <0x20002BF0> and RAM size to <0x3d410> and flash the MCU, I cannot longer connect to it through SWD inside SES - the SES doesn't even see the board. The only way to recover it is to use <nrfjprog> utility while pressing the reset button on the target board quick enough for the utility to catch the beginning of the code execution and before it loops (or at least hard locks indefinitely):

nrfjprog -f NRF52 --recover

I've played with the RAM_START parameter to see what influences the situation, so far that's the results:

  • RAM_START <0x20002BE0> + RAM_SIZE <0x3d420> - error asking to adjust it
  • RAM_START <0x20002BE5> + RAM_SIZE <0x3d410> - error asking to adjust it
  • RAM_START <0x20002BF0> + RAM_SIZE <0x3d410> - hard lock
  • RAM_START <0x20002BF0> + RAM_SIZE <0x3d400> - hard lock
  • RAM_START <0x20002C00> + RAM_SIZE <0x3d400> - hard lock

I've cross-referenced with this tutorial to make sure I'm not missing anything else. Has anyone faced the same issue?

Thanks in advance

  • 0

    Not seen anyting like this before, what happens if you go back to the default example without any modifications and only change to RAM_START=0x20002be0 and RAM_SIZE=0x3d420? (You should get a warning, but it should work.)

    Maybe double check the nRF5 SDK release_notes.txt and check if you are using the correct toolchain for that release? Also, make sure you are using the latest nRF5 SDK.

    Kenneth

Related
Terms of service