nRF5340 PDK resets once Bluetooth is active

RE: nRF5340 PDK resets once Bluetooth is active

helsing — Tue, 18 Aug 2020 14:10:28 GMT

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

RE: nRF5340 PDK resets once Bluetooth is active

pfnsec — Thu, 13 Aug 2020 13:24:51 GMT

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?

RE: nRF5340 PDK resets once Bluetooth is active

helsing — Tue, 11 Aug 2020 14:43:57 GMT

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

RE: nRF5340 PDK resets once Bluetooth is active

helsing — Mon, 10 Aug 2020 14:45:47 GMT

Hi,

I will look into this and get back to you.

Best regards,

Håkon

RE: nRF5340 PDK resets once Bluetooth is active

pfnsec — Mon, 10 Aug 2020 13:24:24 GMT

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.