RAM addressing in SDK v12.2

RE: RAM addressing in SDK v12.2

Vidar Berg — Wed, 14 Nov 2018 08:46:13 GMT

I was able to discover the device programmed with "ble_app_beacon" on my iphone 7 with nRF connect v.1.8.8. Are you using the same version of nRF connect? Old versions of nRF connect will not recognize beacons that are not iBeacon compliant.

The average power consumption depends on your application code. Basically how often you perform the sensor readout and the advertisement interval. You can use the online power profiler here to get an estimate. Note: estimates are based on a device with DCDC enabled, 3V supply and LFXO as the low frequency clock source.

RE: RAM addressing in SDK v12.2

Vijay — Tue, 13 Nov 2018 18:46:50 GMT

Hi Vidar, thanks for the answer! I've got it to advertise. I am sorry I created the issue because the nrf_connect app on iOS doesn't recognize the beacon. I did a "hcitool lescan" on my RPi 3 and it showed up.

This is an useful piece of information about RTC1. I will use the same RAM address on the linker script.

I don't know if I have to create another issue for this but my application involves BLE_advertising, a TWI sensor with an application timer. What are all the flags in sdk_config.h that need to be set for me to ensure the sleep mode current is under 100 uA ?

RE: RAM addressing in SDK v12.2

Vidar Berg — Tue, 13 Nov 2018 08:44:22 GMT

Hi Vijay,

I tried the ble_app_beacon example in sdk 12.2.0 with GCC. The default configuration allocates more RAM memory to the softdevice than what is needed, hence the warning. However, it is safe to ignore, it just let you know that you can free more RAM for the application code. The warning did not show after I adjusted RAM settings in the linker script.

RTC0 is reserved for the softdevice, but app_timer should use RTC1 by default.Have you debugged you application and verified that your program reaches advertising_start()?

Regards,

Vidar

RE: RAM addressing in SDK v12.2

Vijay — Mon, 12 Nov 2018 17:14:07 GMT

Hey Vidar, we have the low frequency - 32.768 kHz - crystal on our board. I was able to get all the defined examples in the SDK working perfectly.

Just a hunch - I have a twi sensor and we were using the nrf_delay function to provide delays while data sampling. We wanted low power and I implemented the delays using the app_timer module. Only after that, we have this problem. I'm using the RTC0 for the app_timer? Will it affect the RAM ? Is there any way to use RTC1 with the softdevice?

I checked the makefile and the linker_script variable is correct. The very same code works perfectly on the devkit.

Thanks

Vijay

RE: RAM addressing in SDK v12.2

Vidar Berg — Mon, 12 Nov 2018 13:59:16 GMT

Hi Vijay,

Strange, so you are editing the ble_app_beacon_gcc_nrf52.ld file adjacent to the project Makefile and the changes are not reflected in the debug log? Please double check that you are editing the correct linker script. You can check out the LINKER_SCRIPT variable in the makefile to see which linker script it invokes for the build.

Also note that the SDK examples are set up to use the optional LF crystal by default. Make sure to change the clock source to the internal RC if you don't have the crystal in your design. Otherwise the program will enter an infinite loop waiting for the crystal to start.

// Low frequency clock source to be used by the SoftDevice
#define NRF_CLOCK_LFCLKSRC      {.source        = NRF_CLOCK_LF_SRC_RC,            \
                                 .rc_ctiv       = 16,                             \
                                 .rc_temp_ctiv  = 2,                              \
                                 .xtal_accuracy = 0} //ignored when using RC