SWO signal inversion bug

[NickT]

OK - so I just started with these chips, and have been asked to find out why SWO debug signal is getting corrupted. 

At fairly random intervals the signal passive state inverts from 0 to 1, which corrupts the next few lines of debug output until the passive state inverts back again.

I suspect a silicon bug, or a conflict between something like GPIO and the ITM, but wanted to start by double-checking the hardware configuration settings.

The SWO is configured as follows, but there are quite a few magic numbers in there.

//
//  brief Initialize the SWO trace port for debug message printing
//      param portBits Port bit mask to be configured
//
void SWO_Init(uint32_t portBits)
{
    uint32_t SWOSpeed = 57600; // baud rate
    uint32_t SWOPrescaler = (CPU_CORE_FREQUENCY_HZ / SWOSpeed) + 1; // SWOSpeed in Hz, note that CPU_CORE_FREQUENCY_HZ is expected to be match the CPU core clock

    CoreDebug->DEMCR = CoreDebug_DEMCR_TRCENA_Msk; // enable trace in core debug */
  *((volatile unsigned *)(ITM_BASE + 0x400F0)) = 0x00000002; // "Selected PIN Protocol Register": Select which protocol to use for trace output (2: SWO NRZ, 1: SWO Manchester encoding)
  *((volatile unsigned *)(ITM_BASE + 0x40010)) = SWOPrescaler; // "Async Clock Prescaler Register". Scale the baud rate of the asynchronous output
  *((volatile unsigned *)(ITM_BASE + 0x00FB0)) = 0xC5ACCE55; // ITM Lock Access Register, C5ACCE55 enables more write access to Control Register 0xE00 :: 0xFFC
  ITM->TCR = ITM_TCR_TraceBusID_Msk | ITM_TCR_SWOENA_Msk | ITM_TCR_SYNCENA_Msk | ITM_TCR_ITMENA_Msk; // ITM Trace Control Register
  ITM->TPR = ITM_TPR_PRIVMASK_Msk; // ITM Trace Privilege Register
  ITM->TER = portBits; // ITM Trace Enable Register. Enabled tracing on stimulus ports. One bit per stimulus port.
  *((volatile unsigned *)(ITM_BASE + 0x01000)) = 0x400003FE; // DWT_CTRL
  *((volatile unsigned *)(ITM_BASE + 0x40304)) = 0x00000100; // Formatter and Flush Control Register
}

So first question - anybody know where I can find the register definitions?

I followed this thread about SWO but it took me to the Infocenter, which has been deprecated and I cannot find a reference manual for the 52832 

Thanks in advance

[NickT]

Hi again,

it turns out that this problem only occurs after we power-cycle the product.  If we look at the logging immediately after programming and while the debugger is still connected, the problem does not manifest.

I have found other support cases around the Cortex that seem to have the same issue.  The only thing that is different in configuration seems to be that the CoreDebug DHCSR C_DebugEn bit is set by the debugger during programming, but is cleared on a power cycle.  Because that bit is only acessible to the DAP, there is no easy way to set and clear it manually, to check what effect it has on the SWO channel.

Hopefully this information will help you to dig a little deeper into the problem?

Nick

[wpaul]

NickT said:

but...

the section on the ITM states this..."Other registers are described in the ARM^®v7-M Architectural Reference Manual."

And that document is "only available to registered ARM customers"...

Just FYI, that manual seems to be available for download here:

https://static.docs.arm.com/ddi0403/eb/DDI0403E_B_armv7m_arm.pdf

Don't know if this helps with your problem though.

-Bill

[NickT]

More information - there is a possibility that the TPIU gets corrupted when the core goes to low power mode.

Is there a way to configure the SDK so that sd_app_evt_wait does not go to low-power modes, for debugging purposes?

Thanks

[NickT]

Thanks Bill,

I had managed to access that - would have been nice if Nordic pointed to it.  I have now got a handle on most of how the SWO is supposed to be setup, although there are a couple of registers that are not well explained even in the ARM documentation.

e.g. DWT control, and "Formatter and Flush Control"

But no amount of tinkering has yet figured out why this works with the debugger connected (i.e. immediately after programming) but corrupts after power-cycling the target.  If we ever get to the bottom of this I'll put it up on this board.

[Edvin]

Hello Nick.

Is it possible to send a project that replicates this?

Are you sure that the signal is inverted, and that it isn't the frequency that is off? Have you tried to scope the signal?

I would still recommend that you try out the UART with only the TX pin, if this is for debugging/logging features only.