Hello!
So I have a new nRF52811 board which was designed by someone else, that I need to develop some pretty simple firmware for.
Full disclosure, the design is based on the nRF example schematic (minus the 32k768 xtal, and plus a couple of I2C peripherals - but the PCB layout is, unfortunately, a mess... I don't expect it to be a good PCB, but I do feel like it should work to at least some extent. (at least to the point where it goes to transmit something!)
I've followed the instructions on how to re-target simulated example projects from the nordic SDK to this new hardware, by adjusting compiler flags and making a custom board header file.
I am happy enough that I'm doing this right because I can re-target the basic peripheral/blinky app, and this board's 1 led is flashing happily when I run that on the custom hardware.
BUT, when I re target the ble_app_template from the ble peripheral folder, I can follow execution from the start of main() right to the point where the softdevice is initialised... I can step into that, and go through the softdevice disassembly for a while, I follow some loops, some pushes and pops, then at some point it ends up locked in a loop inside the softdevice. no error report I can see, no catch, nothing. Here's the eternal loop...
BF20 wfe
F8D40104 ldr.w r0, [r4, #0x104]
2800 cmp r0, #0
D0FA beq 0x00008D9C
Now if this wasn't a proprietary blob where it had hung up, I'd be able to read the code hopefully, and see what kind of check this was caught on... but it is a blob..
I had a bit of a google, and thought that maybe setting NRFX_CLOCK_CONFIG_LF_SRC to 0 instead of 1 in sdk_config.h might help if there was a problem with the crystal - but no such luck. (running the code in emulated mode with this change on the 52840-DK still works..) did the same with CLOCK_CONFIG_LF_SRC and NRF_CLOCK_ENABLED too...
I've also connected to the device and done a full erase with my jlink. I've done that lots of times. So it's not going to be that special section of data flash storing some values that mess up the softdevice. (and when that was happening before on my nRF52840-DK for 52811 emulated projects, when it failed to work because of this I did still end up in an error handler of some sort!)
Oh, and I also modified my re-targeted project to put in a debug configuration (based on the differences I could see in the 10056 project between release and debug) so compiling with optimisation for size on and off, plus the debug flags makes no difference, as expected. since the problem is happening in the softdevice, which isn't compiled here.
Normally my next step would be to try testing the code on a known good eval board for my actual target processor, but there really is very little... The best I can find are a few small module manufacturers with strange stockists, sketchy availability, and probably not so great leadtimes.
So, is there any way to figure out what could be wrong that's causing this softdevice to hang like this?
