Last year David went to an expo where he won a free nRF52 eval board.  Some while afterwards he gave it to me.  On or about 12/7/15 I started playing with it, because I wrote a note about it.

Recently I ran out of steam with the old software and nRF51 hardware.  So I have been trying to program the rRF52, and have been having some success.  But I have encountered a bunch of weird problems that have sucked me into the bog for a week.

It has this funny situation where is appears to run out of RAM at about the 32K mark, but it has 64K. I have been poking around and talking to Nordic who were not much help so far – probably because the problems I describe are so weird.  I’m homing in on the “.ld” file (used to say where bits of the code get placed in memory during loading).

I’m grasping at random ideas now.  I’ve just googled  “nrf52 .ld file” and hit this gem.

@Kirkus: The nRF52 preview chip has some anomaly from the production that we are going to release. You can have a look at the errata here. Issue #33 and #34 are related to your question. There are still 64kB of RAM on the nRF52 preview version, but they are located at 2 locations, each has 32kB. Please follow the information in the errata to declare correct IRAM1 and IRAM2 block.

… this was dated Jun 20th, 2015

I think David got our freebie eval board around this time!

I have no idea if this is the issue but a lot of the symptoms fit.

I checked the chip markings, and we have a QFAABA chip. Even if this isn’t the issue,   I looked at the chip revision errata and it all post-dates Feb 17, 2016 – so I smell a ratty odour.

I was caught by the nRF51 freebies, and now perhaps the nRF52 freebie. I kind of think that using freebies has to be treated with a lot more circumspection from now on.

The lead time here on a replacement from
DigiKey is 18 weeks
Mouser 5 weeks
Arrow “on order”


Now it Istart to see why I am having so much trouble.
https://devzone.nordicsemi.com/question/63766/peer-manager-and-gcc/

So it seems like you might be able to address 64K or RAM but not necessarily in the order that you might assume 🙂

————–

Pls refer this to Håkon!

I think all my arcane problems I reported above are now clear. I have a “preview” system, and most of the problems I am encountering, others have described too. I’d get new hardware, but delivery on the current rev. of the DK seems to be 5-16 weeks!

For reference: I’m using GCC, Eclipse, nrf52 QFAABA1536AA silicon. nRF5_SDK_11.0.0_89a8197

Håkon: Can you confirm that there is a working suite of “.ld” scripts for the nRF52 example ble_app_hrs_rscs_relay/pca10036, or could you consolidate the advice at the following post into one less confusing set of instructions please. The currently posted “.ld” script only specifies 32K RAM.

https://devzone.nordicsemi.com/question/63766/peer-manager-and-gcc/


————-

Hi Michael,
I can confirm that the initial RAM calculation has a bug, and it is the second one reported back that shall be applied:
sd_ble_enable: app_ram_base should be adjusted to 0xsomevalue
The bug lies in macro softdevice_handler.h::CHECK_RAM_START_ADDR_INTERN:
uint32_t app_ram_start_addr = APP_RAM_BASE_CENTRAL_LINKS_##CENTRAL_LINK_COUNT##_PERIPH_LINKS_##PERIPHERAL_LINK_COUNT##_SEC_COUNT_0_MID_BW;
This one is hard to read, I know.
It shall match a corresponding macro in app_ram_base.h, in your case it will incorrectly match:
APP_RAM_BASE_CENTRAL_LINKS_2_PERIPH_LINKS_1_SEC_COUNT_0_MID_BW
However; the macro does not consider the security (crypto) being used in your peripheral link.
For the ble_app_hrs_rscs_relay it shall point to:
APP_RAM_BASE_CENTRAL_LINKS_2_PERIPH_LINKS_1_SEC_COUNT_1_MID_BW 
I’ll of course report this bug internally!
I appreciate the time and effort you’ve also put into catching this bug and helping us continuously improving our delivery.
As an official thank you from me, I can send you one of my nRF52-DKs which has the latest chip revision. 
Just send me your address and phone number (DHL requirement), then I’ll ship this ASAP.
Cheers,
Håkon

Leave a Reply