nRF5340 PDK resets once Bluetooth is active

[pfnsec]

I have tried compiling peripheral_hr in Zephyr, as well as flashing the heart rate demo binaries.

All give the same result - the board simply resets as soon as BLE Advertising is started.

The log from this reset loop is as shown:

[00]*** Booting Zephyr OS build v2.1.99-ncs1  ***
Bluetooth initialized
Advertising successfully started
[00]*** Booting Zephyr OS build v2.1.99-ncs1  ***
Bluetooth initialized
Advertising successfully started
[00][00]*** Booting Zephyr OS build v2.1.99-ncs1  ***
Bluetooth initialized
Advertising successfully started

I have tried nrfjprog --recover, as well as reflashing with compiled hci_rpmsg and other samples, to the same effect.

Is this simply down to a defective board? The reset is not trapped by the debugger, so my suspicion is that some electrical issue is causing a hardware reset.

Thanks in advance.

[pfnsec]

This is the farthest I have gotten so far.

I have modified the light_switch sample to include a little more debug output, but the result is the same: a reset loop!

[00][00][00][00][00][00][00][00][00][00][00][00][00][00]*** Booting Zephyr OS build v2.3.0-rc1-ncs1-1440-g0caecf37c71f  ***

Initializing...Done.

Bluetooth initialized

[1B][1;31m--- 14 messages dropped ---
[1B][0m[00:00:00.027,648] [1B][0m<dbg> bt_gatt.bt_gatt_attr_read: handle 0x000c offset 0 length 5[1B][0m
[1B][1;31m--- 14 messages dropped ---
[1B][0m[00:00:00.032,592] [1B][0m<dbg> bt_gatt.update_range: start 0x0001 end 0xffff new_start 0x0010 new_end 0x0015[1B][0m
Mesh initialized

[00:00:00.039,215] [1B][0m<dbg> bt_gatt.sc_process: start 0x0001 end 0xffff[1B][0m
[00:00:00.042,877] [1B][0m<dbg> bt_gatt.bt_gatt_attr_read: handle 0x0001 offset 0 length 2[1B][0m
[00:00:00.042,907] [1B][0m<dbg> bt_gatt.bt_gatt_attr_read: handle 0x0002 offset 0 length 5[1B][0m
[00:00:00.043,121] [1B][0m<dbg> bt_gatt.bt_gatt_attr_read: handle 0x0005 offset 0 length 5[1B][0m
[00:00:00.043,304] [1B][0m<dbg> bt_gatt.bt_gatt_attr_read: handle 0x0007 offset 0 length 5[1B][0m
[00:00:00.043,334] [1B][0m<dbg> bt_gatt.bt_gatt_attr_read: handle 0x0009 offset 0 length 2[1B][0m
[00:00:00.043,395] [1B][0m<dbg> bt_gatt.bt_gatt_attr_read: handle 0x000a offset 0 length 5[1B][0m
[00:00:00.043,609] [1B][0m<dbg> bt_gatt.bt_gatt_attr_read: handle 0x000c offset 0 length 5[1B][0m
[00:00:00.043,823] [1B][0m<dbg> bt_gatt.bt_gatt_attr_read: handle 0x000e offset 0 length 5[1B][0m
[00:00:00.043,853] [1B][0m<dbg> bt_gatt.bt_gatt_attr_read: handle 0x0010 offset 0 length 2[1B][0m
[00:00:00.044,036] [1B][0m<dbg> bt_gatt.bt_gatt_attr_read: handle 0x0011 offset 0 length 5[1B][0m
[00:00:00.044,097] [1B][0m<dbg> bt_gatt.bt_gatt_attr_read: handle 0x0013 offset 0 length 5[1B][0m
[00:00:00.044,433] [1B][0m<dbg> bt_gatt: Hash: 
28 f6 e2 7e 60 0c ac c1  1e 73 43 8f 61 4b 2f 7b |(..~`... .sC.aK/{[1B][0m
[00:00:00.045,593] [1B][0m<dbg> bt_gatt.db_hash_store: Database Hash stored[1B][0m
[00][00][00][00][00][00][00][00][00][00][00][00][00][00]*** Booting Zephyr OS build v2.3.0-rc1-ncs1-1440-g0caecf37c71f  ***

It can get far enough to be picked up by the nRF Connect app, but it still resets after about 8-9 seconds. It has even stayed up long enough to be provisioned successfully a couple times before resetting.

[helsing]

Could you please try enabling stack protection (CONFIG_HW_STACK_PROTECTION) ?

Also you could try to use the SoftDevice Controller (BT_LL_NRFXLIB) ?

Best regards,

Håkon

[pfnsec]

Thanks for getting back to me.

I have tried these options without success - still resetting - and BT_LL_SW_SPLIT didn't make a difference either.

Thinking it was perhaps triggering a security exception or something, I set 'break z_arm_fault' in gdb attached to the app CPU, in the hopes that I could do a backtrace before it reset.

However, the problem disappears when the breakpoint is set, so I wasn't able to catch anything...


The Heart Rate Monitor demo from 
https://www.nordicsemi.com/Software-and-tools/Development-Kits/nRF5340-PDK/Download

...should definitely work though, right? Since this demo firmware doesn't work, am I right in thinking this points to a hardware issue?

[helsing]

Yes, it sounds like a hardware issue. I am asking our team how to help you.