• State Not Answered
  • Replies 4 replies
  • Subscribers 94 subscribers
  • Views 1553 views
  • Users 0 members are here
Attachments (2) Download All
Nordic Case Info
  • Case ID: 307653
Options

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

grantrudd

Hello,

We are using pc-ble-driver-py and PCA10040 devkits to run automated testing as part of our development process. The recent erratas in the rev. 3 silicon for the 52832 is seeming to cause problems when the devkit is power cycled (https://infocenter.nordicsemi.com/index.jsp?topic=%2Ferrata_nRF52832_Rev3%2FERR%2FnRF52832%2FRev3%2Flatest%2Ferr_832.html).

After a fresh power cycle, the fw_check() function fails and will not work until we run 'nrfjprog --recover' and re-flash the connectivity firmware (connectivity_4.1.4_1m_with_s132_5.1.0.hex). After recovering and reprogramming, our scripts function as expected.

I have tried recompiling the firmware from the v4.1.4 tag with the fix proposed in the errata document (after bringing in a new MDK that supports NRF_APPROTECT), but that doesn't seem to fix the issue. Is there a patch for either pc-ble-driver-py or the connectivity firmware that addresses this issue introduced by the errata?

Thanks,
Grant

Parents Reply Children
  • 0 in reply to JONATHAN LL

    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

  • 0 in reply to grantrudd

    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

    grantrudd said:
    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.

    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..|

Related
Terms of service