Can I use code running on p10028 on a p10001 for the nRF51822

[brianreinhold]

I have some old production code that uses s110 v 5/6 and SDK 8.0.0 (perhaps - no one seems to know). The production device has never been able to do a bonded reconnect correctly, as encryption always failed on the central side. The reason was the flash writes do not work on this nrf51822 p10001 board. The only way I can get flash writes to work is use the debugger and step through the flash writes line by line.

However, I ported the code over to SoftDevice s130 with SDK 12.3.1 and the flash writes DO work but on the development kit. The code is based upon a p10028 board. Could I flash this code on the p10001 board? The only pins being used are for the UART to receive data from the sensor. Clearly I will need to update SoftDevice. Given that all the PINs I configure are the same in p10001 and p10028 I am hoping that it will be compatible. Would this work? This would solve my flash write problem.

[Einar Thorsrud]

Hi,

In principle it should work. However, newer SoftDevices and SDK versions are not always tested on older chip revisions, and workarounds for older revisions may be removed after some time. You can see the SDKs and SoftDevices compatibility matrix for details. Note that things may still work even though not listed as compatible, so if this is not for use in an end product then it should not be a problem.

[brianreinhold]

That reference does not really help - I have already looked at them extensively. What I do not understand is what p10001 and p10028 and those designations mean. I looked at the compatibility matrix some time ago and came up with that the latest SoftDevice I can use with the nrf51822 (which I have) is s130. With that goes the 12.3.0 SDK but I am using all sd_* calls for Bluettooth, pairing/bonding, and flash writes.

[Einar Thorsrud]

Hi,

brianreinhold said:

What I do not understand is what p10001 and p10028 and those designations mean

I should have been more explicit. There i no such thing as p10001, however ther is PCA10001, which is the nRF51 Evaluation Kit. That has long been deprecated and was replaced by the nRF51 Development Kit (PCA10028).

brianreinhold said:

I looked at the compatibility matrix some time ago and came up with that the latest SoftDevice I can use with the nrf51822 (which I have) is s130.

That is correct.

brianreinhold said:

With that goes the 12.3.0 SDK but I am using all sd_* calls for Bluettooth, pairing/bonding, and flash writes.

There is no need to use the SDK if you do not want to, but the compatibility matrix shows which SW and HW products are compatible. So e.g. SDK 12.3 has been integrated with S130 2.0.x, making that a tested and supported combination. But even if you do not use the SDK, a key here is that new SoftDevices has not been tested with earlier chip revisions (e.g. you cannot use S130 2.0.x with revision 1 or 2 ICs, which is why using it with PCA10001 is not supported (though it may work good enough for testing on your desk).

[brianreinhold]

I meant PCA10001 its just that the h-files shortened out the names in the old distribution and dropped the 'ca'. I was unclear of which was the correct designation so I probably used them interchangeably...

Note that I am not talking about testing here. I am working on an actual device that you can buy in the market, I have disassembled it and wired up the SWD which I program through a pca10028 DK. I did do some testing on the DK alone using s130 but that does not allow me to test how the module works with the actual pulse oximeter sensor.

That being said I went ahead and flashed the production device with the s130 2+ and then installed my app written with the s130 SoftDevice APIs. It worked on my production device and it worked on my nrf51 DK which I just bought a few months ago and is designated PCA10028 V1.2.2 1026.44 followed by a serial number.

In the production device the nrf51822 is mounted on something called a YJ-14001-NRF51822 and I have no idea what that means. There aren't any LEDs or buttons on it and the buttons that are in the device are controlled by another module.

Anyways, it appears that at least in this case, the s130 is compatible and I can use the pca10028.h file instead of the pca10001,h file. Note that in your SDK 12.3.0 package the pca10001.h file still exists under components/boards.