Using P0.07 as GPIO, not TRACECLK (nRF52840-QFAA-F-7)

RE: Using P0.07 as GPIO, not TRACECLK (nRF52840-QFAA-F-7)

JWalker — Thu, 15 Feb 2024 07:27:20 GMT

This was the problem. I moved the signal to another pin.

Thanks

RE: Using P0.07 as GPIO, not TRACECLK (nRF52840-QFAA-F-7)

Vidar Berg — Wed, 14 Feb 2024 12:59:25 GMT

Do you have the UARTE0 instance enabled in your project? I'm asking because this pin is assigned to the CTS handshake signal by default (Virtual COM port).

RE: Using P0.07 as GPIO, not TRACECLK (nRF52840-QFAA-F-7)

JWalker — Wed, 14 Feb 2024 09:06:15 GMT

Thanks,

Using above if, it was seen that the pin P0.07 is not in debug mode. Some else is the problem. The LED is connected to VDD_nRF and P0.07 and when set P0.07 to 0 LED should light, but it does not light. Instead a voltage about 2.2V is seen at P0.07.

However I found another register, TRACECONFIG which have TRACEMUX field. After reset it is 0, which means GPIO, and no trace signals are routed. I searched how to access TRACECONFIG register, but did not found it defined. How to access it to see what is its value?

RE: Using P0.07 as GPIO, not TRACECLK (nRF52840-QFAA-F-7)

hmolesworth — Tue, 13 Feb 2024 23:57:58 GMT

You can check it with debug or in the code; default value is 0 which is io pin:

    // TRACE pins can be used as GPIOs or Trace, special case - Debug Exception and Monitor Control Register
    if ( (CoreDebug->DEMCR & CoreDebug_DEMCR_TRCENA_Msk) == CoreDebug_DEMCR_TRCENA_Msk )
    {
        // Debug pin, not io pin
    }

APP-07.pdf