Unable to debug OpenSK on nRF52840DK

[gnmarco]

I tried many times to enable debugging on OpenSK deployed on the nRF52840DK board without success. However, I managed to get the board up and running without debugging.

Actual behavior

1. Execute JLinkExe -device nrf52 -if swd -speed 1000 -autoconnect 1 in a terminal
2. Execute JLinkRTTClient in another
3. Connect board JTAG port to the computer
4. Run ./deploy.py --board=nrf52840dk_opensk --opensk --debug
5. The configuration of the device fails (as expected), but I can see debug output:

Initialization complete. Entering main loop
NRF52 HW INFO: Variant: Unspecified, Part: N52840, Package: QI, Ram: K256, Flash: K1024
Hello world from OpenSK!
Entering main ctap loop
tock$ ...................................................

6. Connect micro USB cable to the USB port of the device (by keeping the JTAG connected)
7. Press "RESET" (debug output stops), this is needed in order for the board to be recognized by the computer.
8. Run

./tools/configure.py \
    --certificate=crypto_data/opensk_cert.pem \
    --private-key=crypto_data/opensk.key

9. The command hangs and the board has LED1 blinking with non-regular intervals.

Expected behavior

In point 7. the output should not stop and point 9. should not happen.

Additional information

Even without the debugger enabled (i.e. without executing steps 1 and 2, it still does not work and I get the same results).
Am I doing something wrong? Is this a known bug? I tried having a look at #561 but I cannot get it to work.

UPDATE

I managed to configure the develop branch of the firmware, but I am still not able to debug using the aforementioned steps. If I change steps (1) and (2) and put them in place of steps (3) and (4) the board complains that it is locked and must be unprotected (by wiping the internal memory, of course, rendering deploy.py useless).

Thanks.

[kaczmarczyck]

I tried to reproduce, and what I agree that the blinking patterns in debug mode are irregular. Could be because the timings are off when OpenSK is slowed down by printing debug output.

In my case, I don't have to press "RESET". But if I do, the debug output also doesn't stop, as long as I keep both cables plugged it. Can you explain why rebooting the chip helps the host OS recognize the board?

Step (8) works without problems for me. I do have to touch at some point, when the terminal says

Please touch the device to confirm...

I'm not sure why your device behaves differently than mine. If you don't mind losing all previously stored data, you can also try if resetting the storage helps:

./deploy.py --board=nrf52840dk_opensk --erase_storage

[gnmarco]

Hi @kaczmarczyck , thanks for your reply.

I tried to reproduce, and what I agree that the blinking patterns in debug mode are irregular. Could be because the timings are off when OpenSK is slowed down by printing debug output.

With the 2.1 branch I can load OpenSK (in debug mode) onto the board, but when I try to configure it (tools/configure.py), LED1 keeps blinking irregularly and the script hangs and times out.

In my case, I don't have to press "RESET". But if I do, the debug output also doesn't stop, as long as I keep both cables plugged it. Can you explain why rebooting the chip helps the host OS recognize the board?

I have absolutely no idea. If I don't press RESET the board is not detected by my host after deployment. I saw that this behavior is documented in OpenSK: "Note: Due to current limitations of our implementation and Tock, you may have to press the BOOT/RESET button, located next to the device USB port on the board in order to see your OpenSK device on your system."

Step (8) works without problems for me. I do have to touch at some point, when the terminal says

Please touch the device to confirm...

With the deploy branch, step 8 works fine. However, I still don't get debug.

I'm not sure why your device behaves differently than mine. If you don't mind losing all previously stored data, you can also try if resetting the storage helps:

./deploy.py --board=nrf52840dk_opensk --erase_storage

Done. And then I followed the steps I outlined before, in this issue. Using the deploy branch I can load ctap2 in debug mode. The device cannot be configured as it appears the system cannot detect it (see above). When I press "Reset", the debug output stops. This is what I see in the debug output:

Initialization complete. Entering main loop
NRF52 HW INFO: Variant: Unspecified, Part: N52840, Package: QI, Ram: K256, Flash: K1024
Hello world from OpenSK!
Entering main ctap loop
tock$ ...........................................................................................................................................................................................................................................................................................................

Then I also tried to leave the debug console opened during the --erase_storage and I correctly saw debug output.
The problem is pressing "Reset", that seems to "protect" again the board and thus, I believe, it does not allow debugging anymore. If I am right, that's why it stops debug output.

BTW, @kaczmarczyck which board version do you have? On mine there is written PCA10056 3.0.2 2024.33.

PS: sorry for accidentally closing the issue. I don't even know how I did it.

[gnmarco]

I managed to solve the problem (in the develop branch). The TockOS version in the repository is too old: new Nordic nrf52840dk boards require a different approach to disable the protection. I have a patch that solves this problem by assuming that the board is a new one (i.e. this may have problems with old boards). In order to solve it I simply copied some code from a newer version of TockOS, which is compatible with both board, but due to the rust-toolchain used by the submodule, the way TockOS used for being compatible with both does not work. I would like to send the patch to be merged, but since this makes the project incompatible with older boards I am not sure on how to proceed.

[kaczmarczyck]

I can confirm that --debug on the 2.1 branch panics when calling ./configure, so the difference in branches explains it! The reason you need to RESET the board is that panic, you can see it in the debugger output.

I will not fix debugging in 2.1, so please use the develop branch from now on. Sounds like the new version of the Nordic board behaves differently from mine?

To fix this, we need a newer or patched version of TockOS, and as a consequence, we'd need a newer toolchain? Just to confirm, having a second board definition is not enough?

[gnmarco]

Hello,

I can confirm that --debug on the 2.1 branch panics when calling ./configure, so the difference in branches explains it! The reason you need to RESET the board is that panic, you can see it in the debugger output.

I need to reset the board even in develop before my computer detects it, both with and without --debug. The difference is now that the board does not enable protections after the reset.

I will not fix debugging in 2.1, so please use the develop branch from now on. Sounds like the new version of the Nordic board behaves differently from mine?

If there will be no fix, perhaps at least an error or a warning on the deploy.py script should be inserted so to avoid wasting people's time to figure out what they did wrong, when they didn't.

To fix this, we need a newer or patched version of TockOS, and as a consequence, we'd need a newer toolchain? Just to confirm, having a second board definition is not enough?

I am not sure. I had to patch tock/chips/nrf52 and tock/boards/nrf52_components. The official TockOS way to do it apparently requires a function called core::ptr::from_ref which was introduced by Rust version 1.76.0 and is therefore not available in the current toolchain. I will try to see if I can remove it or write some replacement code (I am working on it).

[gnmarco]

Ok, I managed to get it to work. Unfortunately now I have NO TIME to read all the legalese involved for signing the CLA. I forked the project and the patch is in my account. The patch is built from TockOS, which means that the Apache License 2.0 applies to that code. I simply collected it in a patch, that's all, anyone could do it. If you want you can retrieve it from there, or I can send a pull request nonetheless, but it will take me some time to do the proper steps for signing the CLA.

[kaczmarczyck]

Thank you for your contribution! For reference, the last comment refers to:
a7bc6ee

I don't generally mind a TockOS version bump, or migrating to a new compiler version. To test this change, I'll have to order a new Nordic board, so I'll keep this open until I have the time and hardware to work on it.

Are you still blocked on anything? It sounds like you were able to resolve your issue, or is anything left that doesn't work after the patch is applied?

[gnmarco]

Thank you for your contribution! For reference, the last comment refers to: a7bc6ee

Yes it does.

I don't generally mind a TockOS version bump, or migrating to a new compiler version. To test this change, I'll have to order a new Nordic board, so I'll keep this open until I have the time and hardware to work on it.

Ok, no problem, so also other people now should have the fix ready to go.

Are you still blocked on anything? It sounds like you were able to resolve your issue, or is anything left that doesn't work after the patch is applied?

Right now no, everything works just fine (in the develop branch).

[kaczmarczyck]

Thanks for the suggestion to add a warning to 2.1, implemented in #715