pc-ble-driver-py and connectivity firmware w/Rev 3 silicon

RE: pc-ble-driver-py and connectivity firmware w/Rev 3 silicon

Vidar Berg — Tue, 23 May 2023 11:53:37 GMT

Hi,

Will your script re-program the DUT with the original connectivity firmware if the fw_check() does not return the expected version number (i.e., v4.1.99 instead of v4.1.4)? I'm basically wondering if there is a chance that the connectivity firmware may be reverted back to the old version where approtect is not being disabled in software

[quote userid="118260" url="~/f/nordic-q-a/99628/pc-ble-driver-py-and-connectivity-firmware-w-rev-3-silicon/426658"]I tried the following sequence of nrfjprog commands and it appears that the patched firmware is not setting the APPROTECT register properly after programming. The behavior is the same with the compiled hex file (v4.1.99) provided in the post above.[/quote]

The board is halted after programming, and the program will not be executed until you perform a reset, either externally or by appending --reset/--pinreset to your programming command.

Here is the result I got when I tested with the 4.1.99 hex:

\sd_api_v5>nrfjprog --program connectivity_4.1.99_1m_with_s132_5.1.0.hex --recover --verify --reset
Recovering device. This operation might take 30s.
Parsing image file.
Verifying programming.
Verified OK.
Applying system reset.
Run.

/* Verify that the SW part of the the access port protection is disabled */
\sd_api_v5>nrfjprog --memrd 0x40000558
0x40000558: 0000005A                              |Z...|

/* Verify that the HW part of the the access port protection is disabled. This register is written during the --recover operation */
\sd_api_v5>nrfjprog --memrd 0x10001208
0x10001208: 0000005A                              |Z...|

/* FW version check. */
\sd_api_v5>nrfjprog --memrd 327680 --w 8 --n 24
0x00050000: 17 A5 D8 46 02 FF FF FF 00 00 00 00 04 01 63 FF   |...F..........c.| //04 01 63 => v.4.1.99
0x00050010: 05 01 FF FF 40 42 0F 00                           |....@B..|

RE: pc-ble-driver-py and connectivity firmware w/Rev 3 silicon

grantrudd — Mon, 22 May 2023 16:03:05 GMT

Hi Jonathan,

I re-compiled with the patch and am still experiencing issues related to the device being locked. It appears that fw_check() is making a call to nrfjprog to read the memory where the version information is stored. This check fails and causes an exception. Here is the traceback:

  File "/home/grant/sram/new_srampy/hardware/bluetooth_nrf.py", line 39, in _scan
    if flasher.fw_check():
  File "/home/grant/.local/share/virtualenvs/new_srampy-9AZ69lLf/lib/python3.8/site-packages/pc_ble_driver_py/ble_driver.py", line 3226, in fw_check
    fw_struct = Flasher.parse_fw_struct(self.read_fw_struct())
  File "/home/grant/.local/share/virtualenvs/new_srampy-9AZ69lLf/lib/python3.8/site-packages/pc_ble_driver_py/ble_driver.py", line 3249, in read_fw_struct
    data = self.call_cmd(args)
  File "/home/grant/.local/share/virtualenvs/new_srampy-9AZ69lLf/lib/python3.8/site-packages/wrapt/decorators.py", line 470, in _synchronized
    return wrapped(*args, **kwargs)
  File "/home/grant/.local/share/virtualenvs/new_srampy-9AZ69lLf/lib/python3.8/site-packages/pc_ble_driver_py/ble_driver.py", line 3280, in call_cmd
    raise RuntimeError(f"{e.__str__()}\n{e.output}")
RuntimeError: Command 'nrfjprog --snr 682853836 --memrd 327680 --w 8 --n 24 --family NRF52' returned non-zero exit status 16.
b'ERROR: The operation attempted is unavailable due to readback protection in\nERROR: your device. Please use --recover to unlock the device.\n'

It seems like the example apps bypass the fw_check() step and discover all Nordic devices connected to the computer. The fw_check() is important in our testing as our system includes multiple DKs, some of which are running custom FW and acting as the DUT, while others are programmed with connectivity to exercise the DUTs.

Are there any other registers that we can modify to disable readback protection?

Thanks,

Grant

edit: I tried the following sequence of nrfjprog commands and it appears that the patched firmware is not setting the APPROTECT register properly after programming. The behavior is the same with the compiled hex file (v4.1.99) provided in the post above.

nrfjprog --recover
nrfjprog --memrd 0x40000558
   0x40000558: 00000000 
nrfjprog --program connectivity_4.1.4_1m_with_s132_5.1.0.hex --sectorerase
nrfjprog --memrd 0x40000558
   0x40000558: 00000000

RE: pc-ble-driver-py and connectivity firmware w/Rev 3 silicon

JONATHAN LL — Mon, 22 May 2023 07:32:12 GMT

Update:

This should help:
Testing a fix, add his line '*(volatile uint32_t *) 0x40000558 = 0x5A;' to the beginning of main() by editing the patch file here:

https://github.com/NordicSemiconductor/pc-ble-driver/blob/master/hex/nRF5_SDK_15.3.0_connectivity.patch

devzone.nordicsemi.com/.../nRF5_5F00_SDK_5F00_15.3.0_5F00_connectivity.patch devzone.nordicsemi.com/.../7801.sd_5F00_api_5F00_v5.zip

patch file and connectivity hex files above:
Regards,
Jonathan

RE: pc-ble-driver-py and connectivity firmware w/Rev 3 silicon

JONATHAN LL — Thu, 11 May 2023 14:05:12 GMT

Hi Grant,

Thanks for informing us, I will report this back to our developers so that we can get this fixed.

Regards,
Jonathan