nrf51822 qfaa has problem with eddystone example

RE: nrf51822 qfaa has problem with eddystone example

MartinBL — Wed, 13 Sep 2017 15:35:09 GMT

It sounds like you got it right. The reason you sometimes have to debug and get the address from 'app_ram_base' is that the Softdevice requires different amounts of RAM according to how many services and characteristics you have, what bandwidth configuration you use, etc.

RE: nrf51822 qfaa has problem with eddystone example

secondbest — Wed, 13 Sep 2017 07:31:46 GMT

Hi Martin;

Thank you for your response. After I reviewed webpage about ram and rom management, I think i found a solution. According to web page, If s130v2 is used, ram settings of the nrf51822_qfaa is IRAM base - 0x20001870 and size - 0x2790(16kb). I set up my code with these IRAM settings. After that my code start to work. However, it is continuously reset and start again because my iram start address is not correct. To learn what it is iram base(start) adress, i add a break point inside the softdevice_enable() function. I think that "app_ram_base" variable inside softdevice_enable is our IRAM start adress and it is equal to 0x20001FE8 at debug. We can also easily calculate the our ram size. It is equal to (0x2790 - (0x20001FE8 - 0x20001870)) = 0x2018. When Iram base adress is 0x20001FE8 and size is 0x2018, eddystone example code have started to work correctly.

Is this valid solution? Or, Does my code hang in some situation?

RE: nrf51822 qfaa has problem with eddystone example

MartinBL — Tue, 12 Sep 2017 15:23:51 GMT

Hi,

Here is a great writeup about RAM and ROM management.

I suppose one solution might be to go back to an earlier SDK, like e.g. SDK 11. It has less features added to the example and is only experimental, but it seems like you can just about fit the example onto a QFAA chip. I think removing unnecessary features from the SDK 12.3 version will be a major hassle and it might not be possible to remove enough either.