How to check the DAP is not closed properly

[Maverick2k]

Dear all,

In the datasheet and online it is mentioned that the DAP (Debug Access Port) is activated when a programmer is attached. Moreover, it can happen that the programmer is removed without the DAP being deactivated. The product I am using is an nRF52840 and I have the following questions:

• How can you determine if the DAP is activated with the use of firmware (reading a register)?
• Secondly, how can you make sure the DAP is deactivated, without a complete power cycle? Since a power cycle is not an option.
• What behavior is influenced when the DAP is activated? E.g. timers, sleep, etc?

Looking forward to your reply.

Thanks

[Vidar Berg]

Hello,

If I recall correctly, it is only possible to power down the debug interface externally via the debug interface. I also do not think it is possible to check programmatically if the chip is in debug interface mode or not. But I will ask internally to confirm.

What behavior is influenced when the DAP is activated? E.g. timers, sleep, etc?

In debug interface mode, the system will keep certain resources needed for debugging active as stated here in the PS: Emulated System OFF mode. This will normally not have any affect on the functional behavior of your device, except for shorter wake up times for interrupts.

Secondly, how can you make sure the DAP is deactivated, without a complete power cycle? Since a power cycle is not an option.

Can you measure the current consumption? The "sleep" current in debug interface mode is around ~3 mA.

Best regards,

Vidar

[Maverick2k]

Hello,

Thank you for your reply. Unfortunately, the device is fully molded with no access to the power source, so also not for measuring. I can conduct wireless updates, but if there is no way to check if the DAP is activated and or disable it, there is no use.

If you find out more information internally let me know.

Thank you in advance.

[Vidar Berg]

Hello,

There does not appear to be a good way to programmatically detect whether the chip is in debug interface mode, unfortunately. You have the C_DEBUGEN bit in CoreDebug->DHCSR (link), but this register is only reset after a power-on reset (i.e. it will remain set after the debugger has exited debug mode).

I think your best option is to verify that your programming setup is exiting debug mode after programming as it is supposed to on a device that has not been encapsulated.