Using nRF52832 (Cortex M4) and have configured the SWO to output debug printing.
This works fine immediately after programming, but there is intermittent corruption if the debug/programmer is disconnected and the product is power-cycled.
Setup code is...void SWO_Init(void){uint32_t SWOSpeed = 57600; // default baud rateuint32_t SWOPrescaler = (CPU_CORE_FREQUENCY_HZ / SWOSpeed) + 1; // SWOSpeed in Hz,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 :: 0xFFCITM->TCR = ITM_TCR_TraceBusID_Msk | ITM_TCR_SWOENA_Msk | ITM_TCR_SYNCENA_Msk | ITM_TCR_ITMENA_Msk; // ITM Trace Control RegisterITM->TPR = ITM_TPR_PRIVMASK_Msk; // ITM Trace Privilege RegisterITM->TER = 1; // ITM Trace Enable Register. Enabled tracing on stimulus port 0*((volatile unsigned *)(ITM_BASE + 0x01000)) = 0x400003FE; // DWT_CTRL*((volatile unsigned *)(ITM_BASE + 0x40304)) = 0x00000100; // Formatter and Flush Control Register}
We have used the CMSIS SWO_Putchar (core_cm4.h), and tried modifying it to allow for Fifo-full blocking, and re-written it to use exclusive (STREXNE) register accesses. These did not affect the symptoms.
I think this problem has been seen in other places - https://community.arm.com/developer/ip-products/processors/f/cortex-m-forum/8934/problem-with-swo-when-debugger-not-connected
But no solution has been posted as far as I can tell.
We have also dumped the registers, and the only difference we can find in the coredebug registers is that C_DEBUGEN is set when the SWO is reliable, and is clear when it is not...
The ref manual states that this bit is only accessible through the DAP, so I cannot think of an easy way to test its influence on the problem.
Does anybody have any ideas about this?
Thanks
View all questions in Cortex-M / M-Profile forum