[SOLVED] SWO uart output corruption

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [SOLVED] SWO uart output corruption

    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
  • Hello,

    Thank you for your inquiry.
    When using SWO we recommend letting J-Link software handle any SWO specific settings as the debug probe and target devices have to negotiate a fitting SWO speed which can be impacted by many factors.
    Additionally the SWO clock sourcing is a bit different on the nRF52 series than on other Cortex-M devices.
    See here for more information:
    wiki.segger.com/NRF52_Series_Devices#SWO
    So to use this we recommend removing any SWO related init from your application and let the J-Link software handle everything. You only have to make sure that SWO is enabled in the debug software or IDE you are currently using.

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.