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?

[wz2b]

By the way, I noticed in that sample project that flash_placement.xml refers to a bunch of variables that didn't seem to be set anywhere, so I went into settings / common / linker and set placement macros:

FLASH_PH_START=0x0

FLASH_PH_SIZE=0x100000

RAM_PH_START=0x20000000

RAM_PH_SIZE=0x40000

FLASH_START=0x1000

FLASH_SIZE=0xDF000

RAM_START=0x20000008

RAM_SIZE=0x3FFF8

What does PH stand for?

[wz2b]

Reading this document https://devzone.nordicsemi.com/nordic/short-range-guides/b/getting-started/posts/adjustment-of-ram-and-flash-memory it seems like I have this wrong.  So I changed it based on this:

S140

7.0.0

0x20001678

0x27000

I've actually got 7.0.1 but I figured this would at least get me closer.

S140 7.0.1 seems to have a bootloader in it, so I specified blinky plus s140 7.0.1 and the programmer is happy and flashes it ... but it doesn't run.  So it's still not right, but I feel like I'm on the right track.

[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]

I answered this question myself: PH means physical.  So it looks like you're defining the physical limits first, then the remainder tells what memory your application can use.