This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

SWO signal inversion bug

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

Parents
  • Edvin,

    Thanks for the information about how to use the UART.

    Unfortunately that is not what we are trying to fix...on our hardware, the SWO pin is available on a connector, the UART pin is not.

    To recap,

    We have an implementation that uses the SWO in NRZ node (0xE00400F0 = 2)

    with a pre-scalar (0xE0040010 = 556) which generates a baud rate of 57600 (0.01% error) from the 32MHz TPIU sysclock.

    This works, we can connect a terminal to the SWO pin and "see" the internal log messages.  But it is unreliable - every so often the data is corrupted because the SWO inverts its passive state.

    What I am trying to discover is why the SWO does not behave reliably in this configuration.

    I hope that is clear now?

  • Hello,

    I am sorry for the late reply. We have had public holiday in Nordic from Thursday until yesterday. 

    I believe I understand. But you do not have a programming chip on the device, right? Do you use a debugger to monitor this SWO pin? You can set the UART pin to whatever pin you like, so I don't really see this limitation. 

    Do you have a project file that I can run on a DK that can replicate this issue?

    BR,

    Edvin

Reply
  • Hello,

    I am sorry for the late reply. We have had public holiday in Nordic from Thursday until yesterday. 

    I believe I understand. But you do not have a programming chip on the device, right? Do you use a debugger to monitor this SWO pin? You can set the UART pin to whatever pin you like, so I don't really see this limitation. 

    Do you have a project file that I can run on a DK that can replicate this issue?

    BR,

    Edvin

Children
  • 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

Related