Problem Loading Bonding Info From Flash

[Eric]

Unless manually set the value of bond_init_data.bonds_delete to true in the function bond_manager_init to clear bonded masters, I end up in the HardFault_handler. The last call I can trace is line 641 in pstorage.c,memcpy (p_dest, (((uint8_t *)p_src->block_id) + offset), size); From that code it doesn't look like a memcpy is ever expected to fail.

The example I'm primarily working on is the experimental ble_app_ancs, but it occurs in other examples as well. I am using the latest SDK and soft device, but this has happened with the previous version as well.

I suspect this is related to my target setup, but I'm just using the defaults from the example project - nrf51822_xxaa_s110 (256). I've had a look at the Dev Kit User Guide, but those numbers seem to be different.

How do I go about finding the source of this issue?

Thanks, Eric

[Ole Morten]

A HardFault can be caused by a number of different reasons, but one of them is unaligned access. Even though the line above the one you quote is supposed to catch this, can you please check what the pointer values are at the point where you suspect it fails?

Also, even when you get a HardFault, you should be able to see a backtrace to the point that caused it with version 6.0.0 of the softdevice. What do you see in the call stack window when you put a breakpoint in the HardFault handler?

A HardFault is also what will happen if you try to do an operation that the MPU forbids, or try to access flash/RAM outside the valid areas. This does however seem unlikely in this case, unless you have very strange values for the flash pages used for bonds and system attributes, but it could be worth checking.

If you still have trouble, could you please share your complete project? As normal, if you need confidentiality, please create a support case on our regular web site.

Edit: Rephrased somewhat in first and third paragraph.

[Eric]

Attached is a screen shot with the stack at HardFault, also a stack just before the memcpy that causes the HardFault.

I get this fault with all the ble projects at the moment. Those screen shots are from an unmodifed copy of ble_app_proximity (well I changed the optimisation so the stack trace has more info for the second screen shot).

ble_app_proximity.7z

[Ole Morten]

I just tried to reproduce this, with the project and hex you uploaded, but I'm not able to. The values for the memcpy() parameters also looks good in your screenshot, but I find it strange that you don't get a backtrace from your HardFault. Can you please make sure that you use softdevice 6.0.0, which is required for SDK 5.0.0? Also, can you please read off the laser markings on your chip, and post them?

[Eric]

I'm using version 6.0.0.5 of the soft device, attached is a screen shot from nRFgo Studio with the verification.

The markings on the chip read:

N51822
QFAAFA
1319AA

The sticker on the PCB reads:

PCA10004
Rev. 2.1.0
2013.25
10001609

[Ole Morten]

Based on your latest studio screenshot, it seems there is something odd about your chip (region 1: 4096 kB is not correct). Please create a support case and refer to this thread, and I'll make sure it is handled as soon as possible.