Reading FICR through SWD on nRF52832

Hello,

I am working on a SWD flasher for nRF52 chips. I try to perform basic commands like flashing a firmware or reading flash content. I wanted to use FICR informations such as "Codepage size" or "Codesize" to calculate the size of the firmware loaded on the chip for the read command. How ever, I struggle to read the content of these registers. I managed to write to the NVMC config register for example but reading the FICR registers always returns me a 0. I also received 0 for the Flash Variant. I checked the implementation made on this Github project (https://github.com/atc1441/ESP32_nRF52_SWD) and I have similar implementation regarding the writing and the reading of these register. Though I do not understand why they are reading twice the RDBUFF Debug Port to get the return value of their AP Read nor why they check RDBUFF after AP write in this example. The ARM Debug Interface v5 Architecture Specification do not mention reading twice RDBUFF in their paragraph regarding " Posted Read Accesses to the AP" (https://developer.arm.com/documentation/ihi0031/a/The-Serial-Wire-Debug-Port--SW-DP-/Protocol-description/The-OK-response?lang=en).

Is there something I need to do to unlock access to this specific register (like halting the chip or writing to some specific register maybe)? If so, how can I perform these steps?

Parents
  • Hi

    Okay, so this seems to be an issue with the SWD flasher and SWD you're using since it seems to be working on the J-Link just fine. And in that case we don't have much in terms of suggestions I'm afraid. Is your SWD flasher powered externally, and with what voltage in that case? 

    Is there a reason you can't use J-Link and the nrfjprog commands for flashing/reading the memory of these devices? If it makes sense for your use case you could also make the application read and print the FICR addresses you want to read with something like NRF_FICR->DEVICEADDR[] in the application code, but I guess that's a "hacky" workaround at best.

    When the registers return a 0 that points to the device being unable to or not allowed to read the registers, but I don't see why they would be protected at all.

    Best regards,

    Simon

Reply
  • Hi

    Okay, so this seems to be an issue with the SWD flasher and SWD you're using since it seems to be working on the J-Link just fine. And in that case we don't have much in terms of suggestions I'm afraid. Is your SWD flasher powered externally, and with what voltage in that case? 

    Is there a reason you can't use J-Link and the nrfjprog commands for flashing/reading the memory of these devices? If it makes sense for your use case you could also make the application read and print the FICR addresses you want to read with something like NRF_FICR->DEVICEADDR[] in the application code, but I guess that's a "hacky" workaround at best.

    When the registers return a 0 that points to the device being unable to or not allowed to read the registers, but I don't see why they would be protected at all.

    Best regards,

    Simon

Children
No Data
Related