Working with nRF53832 Cortex M4
SWO output is configured for UART logging stream. Setup code is...
void SWO_Init(void)
{
uint32_t SWOSpeed = 57600; // default baud rate
uint32_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 :: 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 = 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
}
when connected to J-link it works fine, but after a power-cycle, when running standalone the SWO data gets occasionally corrupted. It looks like the TPIU fifo read is not accurate, but we have tried protecting it with exclusive read/write assembler and the SWO still misbehaves.
Very similar problem was reported here e2e.ti.com/support/tools/ccs/f/81/t/471351#
Have dumped the associated registers and the only difference seems to be in Coredebug DHSCR, C_DebugEn bit is set when SWO is working correctly, but is clear when it is not.
Would like to prove that the value of this bit is associated with the problem.
Is there an easy way to clear DHSCR, C_DebugEn on a running target? It seems it cannot be accessed from software, only via the DAP. And only gets reset via a power-cycle.
Thanks
SWO output is configured for UART logging stream. Setup code is...
void SWO_Init(void)
{
uint32_t SWOSpeed = 57600; // default baud rate
uint32_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 :: 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 = 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
}
when connected to J-link it works fine, but after a power-cycle, when running standalone the SWO data gets occasionally corrupted. It looks like the TPIU fifo read is not accurate, but we have tried protecting it with exclusive read/write assembler and the SWO still misbehaves.
Very similar problem was reported here e2e.ti.com/support/tools/ccs/f/81/t/471351#
Have dumped the associated registers and the only difference seems to be in Coredebug DHSCR, C_DebugEn bit is set when SWO is working correctly, but is clear when it is not.
Would like to prove that the value of this bit is associated with the problem.
Is there an easy way to clear DHSCR, C_DebugEn on a running target? It seems it cannot be accessed from software, only via the DAP. And only gets reset via a power-cycle.
Thanks