Should ble_app_blinky_pca10059_s149 work out of the box?

[wz2b]

I received my NRF52840 dongles and downloaded SDK 16.0.0 and SES 4.52c.  I found some old documentation that said how to convert ble_app_blinky to the dongle but then exploring the SDK it looks like there's a project already configured for the dongle:

    examples\ble_peripheral\ble_app_blinky\pca10059\s140\ses

so I built it and got a HEX file.  But that hex file doesn't work.  When I load it up in nRF Connect's programmer I think I can see why.

The file I generated:

    65,847 ble_app_blinky_pca10059_s140.hex

but there is a pre-built binary located in examples\ble_peripheral\ble_app_blinky\hex\ble_app_blinky_pca10059_s140.hex

    504,895 ble_app_blinky_pca10059_s140.hex

I went into the programming utility and I added an MBR file

    mbr_nrf52_2.4.1_mbr.hex

then I went to add a soft device from components\softdevice\s140\hex:

    438,258 s140_nrf52_7.0.1_softdevice.hex

That soft device file plus the mbr file plus my example .hex file adds up to about the right size, so that seemed right ... but when I add all three to the programming utility, it warns me of overlapping regions.  And, obviously, it doesn't work.  When I download that pre-built image it works great.

I don't mind doing these steps manually for now... but what am I doing wrong?

[Einar Thorsrud]

Hi,

The example (<SDK16>examples\ble_peripheral\ble_app_blinky\hex\ble_app_blinky_pca10059_s140.hex) works out of the box. The only difference between this and the example you build yourself is that the examples in the hex folder are merged with the SoftDevice. So you will get the same result by merging the SoftDevice hex (<SDK16>\nRF5_SDK_16.0.0_98a08e2\components\softdevice\s140\hex\s140_nrf52_7.0.1_softdevice.hex), or by simply adding both files to the nRF Connect programmer.

The reason you are getting a conflict when adding the MBR hex file as well is that the SoftDevice hex file contains the MBR, so there will be overlap. And in any case, adding the MBR has no point, since it is already present and is anyway stripped away before programming (via USB DFU).

[wz2b]

OK, that explains why the conflict in the programmer.  Mine still doesn't run, though.  Does the entry point of my application need to be at an exact address in order for the bootloader to detect it?  I'm following the out-of-the-box compiled one which places the flash at 0x27000.  I did that, my map shows this:

*(.vectors .vectors.*)
.vectors 0x0000000000027000 0x200 Output/ble_app_blinky_pca10059_s140 Release/Obj/ses_startup_nrf52840.o
0x0000000000027000 _vectors

[wz2b]

Yeah.  I think that's right, the startup address for s140  7.0.1 should be 0x27000.  I couldn't find that in the release notes so I'm not sure where I should be looking.  I'm guessing on the RAM but this is blinky so it shouldn't need much, so I guessed:

    FLASH_START=0x27000
    FLASH_SIZE=0xD9000
    RAM_START=0x20004000
    RAM_SIZE=0x3C000

which probably give SoftDevice more RAM than it actually needs.  The application runs now, but not for very long - I can see it advertise but when I try to connect it just crashes / stops sending advertisements / stops responding.

[Einar Thorsrud]

Hi,

The memory layout needs to be correct (which it is in the unmodified SDK example). The MBR is on the first page, then the SoftDevice starts on page 1 (address 0x1000), and the application must start immediately after SoftDevice. So for S140 7.0.1 the size is 0x27000 bytes including the MBR, meaning that the application start address also has to be 0x27000. So this is correct. The FLASH_SIZE should be set so that FLASH_START + FLASH_SIZE is lower than the start address of the bootloader.

When it comes to RAM, the RAM start address and size is dictated by the SoftDevice configuration, as described here. But again, if you use an unmodified example you can use the configuration as is without changing anything. But setting a higher RAM start address and lower size as you do is not a problem (unless you need the additional RAM).

wz2b said:

The application runs now, but not for very long - I can see it advertise but when I try to connect it just crashes / stops sending advertisements / stops responding.

In such cases, having a DK to test on is very helpful, since using the onboard debugger will give you a good insight into what is happening. Do you have a DK? If so you can use the exact same firmware you use on the dongle on the DK to test on.

[wz2b]

I don't have a DK but I'll get one.  I figured out the app doesn't actually crash, it's still sending out advertisements.  But I can't "Connect" from nRF connect.

[wz2b]

OK.  I took the SDK zip file and unpacked the ble peripheral blinky app again, and this time I just compiled it with ZERO modifications.  It behaves exactly the same - I can see that it's running, it's sending out advertisements, but I can't connect to it.

Also, I ordered a DK, but it would be nice to figure this out before it gets here, if I can.  Is there a .map file for the pre-compilex .hex in the SDK (in the ble_app_blinky/hex folder) that I can compare to mine? 

[Einar Thorsrud]

Hi,

Summing up:

• The prebuilt hex file works as expected
• The unmodified SDK 16 example that you build yourself advertises, but there is an error after connecting to it.
• You build with SES 4.52c

As you have reverted all changes (extracted a fresh SDK zip), then the only difference on the nRF side is the toolchain. However, I just tested now building with SES 4.52c, and it still works as expected. This leaves a few possible explanations.

Can you clarify if you have made sure the entire SDK is unmodified, or if you just made sure that the BLE blinky application is unmodified? Could it be that you (accidentally or purposely) modified an SDK file that causes misbehavior?