hang after flash.. no output chip rev2 soft device incompatible???

[colin_was_here]

Hi all,

I'm having this really strange issue with the wrong hardware+software+soft combos... Last week I merged together a program that incorporates the following: SDK15, FreeRtos, and s140 7.2.0.. this software runs and executes fine on 2 out of the 3 boards I have in front of me.. but not on the only one I actually want to run it on :)

The issue itself is pretty easy to explain, after I build + flash(in debug mode), it says flash success and then just doesn't do anything.. it does not pause on the start of main like it should and I do not get any of my printfs on the debug console like I should, the board just sort of sits there and the cycle counter remains at 0. It's 100% repeatable(with certain hw)..

So we're using the bl654 which are pre-certified modules for the nrf52840.. so the boards I have in front of me are as follows...

laird bl654 eval kit.. bl654-1.0, this has a v1.0 nrf52840..  (works fine)

pca10056 eval kit, version 2.0.1 (works fine) , I'm honestly not sure which version of the chip this has, the pcn notification on it's page isn't very helpful.

my own custom breakout board.. with bl654 r3.0. According to laird these have the latest v2 nrf52840 on them.. problem?? I don't know..

before you say 'check you're hardware' - I did.. the only thing I have on my breakout board was a bl654 R3, 32k xtal+caps, one very blue LED and the swd connector+100k pull up on rst. It's really just an easier way to hand solder the bl654. The first thing I did with this board when I got it in is power it up and run the rtc example, that blinks the led from the rtc, this works great.. I also tested some printfs and made sure that the lf clock was sourced from my own crystal.. so the crystal+led+debugger has been well tested. this is the board that wont seem to run my latest software though..

so the breakout board isn't connected ot anything else besides pwr(from hv) so it won't do much yet until I solder it to the master board.. in future.. but it should print out some stuff.. At first I thought this was a power issue, since the regulator vdd, defaulted to 1.8v.. I found some post about how to set regout0 however and now it seems happy at 3.3..

anyways.. this hardware works fine, and this software works fine.. but when I put them together... nothing happens.. I guess I'm suspecting a version comparability issue at this point.. but if this were the case, I would expect it either not to compile, or to have some wierd runtime behavior/bugs, not a total hangup like i'm seeing...

so, I've looked at the compatability matrix and it says that with sdk15 I should be using s140 v6, not v7.. no?? if this is the case then I guess I'm also wondering how that switch would be done? where exactly is that defined?

the other thing I'm wondering Is is about the chipset revisions.. I know for sure that the laird one on my breakout is soc rev2 and the laird eval kit contains rev1(one of the engineering ones I guess)... so that's a major difference right there..

What I'm not sure about is which soc version the pca10056 v2.0 is?? in the pcn it says that they upgraded the chip version but they don't say to which rev?? my problem might be with version 2 of the soc but I'm not sure.. if the pca10056 has the latest soc then it would disprove this theory see?

but I could be wrong about all that too.. ;)

anyways, if you've run into anything like this before it'd be great to know what you did to fix it?

thanks, Colin

[hmolesworth]

Is it possible that the softdevice is already loaded on the 2 working boards?

There is a memory alignment issue if using a softdevice which differs from the project settings, which will happen if using SDK15 and SDv7 without adjusting the linker settings and indeed possible the include files at .\components\softdevice\s132\headers\ which are softdevice version dependent. Since the SDK v15 uses SD v 6, how come SD v7 is getting loaded in the first place?

Anyway, the softdevice is defined in the SDK v16 or v17 project file like this:

debug_additional_load_file="../../../../../../components/softdevice/s140/hex/s140_nrf52_7.2.0_softdevice.hex"

SDK v15 uses (typically) v6.1.1 like this:

debug_additional_load_file="../../../../../../components/softdevice/s140/hex/s140_nrf52_6.1.1_softdevice.hex"

The Sofdevice has to be specified in the project file Optons->Preprocessor Definitions as either 6 or 7:

NRF_SD_BLE_API_VERSION=7

The link map must match (this is nRF52840 SD V7.2.0):

linker_section_placement_macros="FLASH_PH_START=0x0;FLASH_PH_SIZE=0x100000;RAM_PH_START=0x20000000;RAM_PH_SIZE=0x40000;FLASH_START=0x27000;FLASH_SIZE=0xd9000;RAM_START=0x20002ae8;RAM_SIZE=0x3d518"

this is nRF52840 SD V6.1.1:

linker_section_placement_macros="FLASH_PH_START=0x0;FLASH_PH_SIZE=0x100000;RAM_PH_START=0x20000000;RAM_PH_SIZE=0x40000;FLASH_START=0x26000;FLASH_SIZE=0xda000;RAM_START=0x20002a98;RAM_SIZE=0x3d568"

Maybe the best starting point is to compare a BLE example project .emProject with the project you are using; the differences should be apparent.

More info here

https://infocenter.nordicsemi.com/topic/sds_s140/SDS/s1xx/mem_usage/mem_usage.html

You can check the Rev.2 stuff by looking at NRF_FICR->INFO in the debugger or via a printf

[colin_was_here]

hmoles-

thanks for the info.. last night I tried out what you said and diffed the emproject file, turns out it was on sdk17 all along, and it did match up in terms of flash adresses :).. then I looked into the NRF_FICR register and found out that they were all on AD, except for the laird eval kit which was on AC, this ruled out the hardware version as the issue..

So at that point I was pretty disappointed and called it a night.. coming in this morning I talked w a coworker who thought it'd be worth it to just erase the entire chip and re-flash.. I didn't actually think that'd work but I gave it a shot.. low and behold it booted perfectly and stopped at main this time.. :)

I gotta say I was pleasantly surprised by this.. when I was flashing before it would always say 'contents already match' for the softdevice.. then it would flash my app if it was different.. I always assumed that it was actually checking and comparing the flash... but apparently not.

anyways- takeaway is that I /you should always fully erase the chips from laird.. they come pre installed with a bunch of firmware and it's not enough just to flash over it..

Thx, Colin