On the latest master of https://github.com/nrfconnect/sdk-nrf (v1.7.0-rc1), swapping between extended and standard advertising will result in reads/ attempted writes to address 0x00.
Depending on the application configuration, this will result in either a hard fault, or advertising the contents of flash at 0x00 instead of the expected AD structures.
I have attached a modification of the standard scan_adv Zephyr sample which demonstrates this issue consistently on a Particle Argon board within the first few seconds.
With CONFIG_MPU_ALLOW_FLASH_WRITE enabled, the sample will advertise flash contents, if it is disabled it will hard fault inside the softdevice with:
[00:00:02.017,028] <err> os: ***** MPU FAULT ***** [00:00:02.017,059] <err> os: Data Access Violation [00:00:02.017,059] <err> os: MMFAR Address: 0x0 [00:00:02.017,059] <err> os: r0/a1: 0x00000000 r1/a2: 0x20008ec1 r2/a3: 0x0000000d [00:00:02.017,059] <err> os: r3/a4: 0xffffffff r12/ip: 0x00000002 r14/lr: 0x0001a955 [00:00:02.017,059] <err> os: xpsr: 0x01000000 [00:00:02.017,059] <err> os: Faulting instruction address (r15/pc): 0x000166f2 [00:00:02.017,089] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0 [00:00:02.017,089] <err> os: Current thread: 0x20001f38 (unknown)
Softdevice version information:
[00:00:00.006,347] <inf> sdc_hci_driver: SoftDevice Controller build revision: 3f 47 70 8e 81 95 4e 86 9d d3 a2 95 88 f6 30 0a |?Gp...N. ......0. 7f 53 49 fd |.SI. [00:00:00.007,751] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002) [00:00:00.007,751] <inf> bt_hci_core: HW Variant: nRF52x (0x0002) [00:00:00.007,781] <inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 63.28743 Build 1318420878 [00:00:00.008,483] <inf> bt_hci_core: Identity: DA:04:3D:69:EA:9B (random) [00:00:00.008,483] <inf> bt_hci_core: HCI: version 5.2 (0x0b) revision 0x125b, manufacturer 0x0059 [00:00:00.008,483] <inf> bt_hci_core: LMP: version 5.2 (0x0b) subver 0x125b
This issue can be worked around by destroying and recreating the advertising set each time advertising is started, however I cannot validate if this simply makes the error less frequent.
As an example of received packets on a remote device of the sample application, where the 05 FF packets are valid and 28 64 00 20 packets are the flash contents at 0x00 (Stack pointer):
[02:48:22.000,061] <inf> app: 01/01/2020 02:48:59.00002 [02:48:23.000,061] <inf> app: 01/01/2020 02:49:00.00002 [02:48:23.717,254] <wrn> uc_bt_adv: ADV PKT 28 64 00 20 11 ac |(d. .. [02:48:24.000,061] <inf> app: 01/01/2020 02:49:01.00000 [02:48:24.722,106] <wrn> uc_bt_adv: ADV PKT 05 ff ff ff d5 00 |...... [02:48:25.000,030] <inf> app: 01/01/2020 02:49:02.00000 [02:48:25.720,336] <wrn> uc_bt_adv: ADV PKT 05 ff ff ff d7 00 |...... [02:48:26.000,030] <inf> app: 01/01/2020 02:49:03.00000 [02:48:26.723,693] <wrn> uc_bt_adv: ADV PKT 28 64 00 20 11 ac |(d. ..