JN518x: SWO trace for debugging works... but has some issues.

[usaygo]

Hello,

I'm using JN518x over DK6 board and trying to debug feature with SWO trace. It may work but it has some issues on my place.

• Issue#1: The initial linking to SWO fails so many times.
• Issue#2: Console messages is not output properly when using Newlib or NewlibNano.

The attachment is newly built from project wizard and made a small modification using SDK2_6_4.

In pin_mux.c: added PIO14 entry as SWO.

// ADDED PIO14 ENTRY AT pin_mux.c
    IOCON->PIO[0][14] = ((IOCON->PIO[0][14] &
                          (~(IOCON_PIO_FUNC_MASK | IOCON_PIO_DIGIMODE_MASK)))
                         | IOCON_PIO_FUNC(PIO0_14_FUNC_ALT5)
                         | IOCON_PIO_DIGIMODE(PIO0_14_DIGIMODE_DIGITAL));

In clock_config.h: change clock as 3MHz (may not be necessary)

    CLOCK_SetClkDiv(kCLOCK_DivTraceClk, 16U, false);   /*!< Set TRACECLKDIV divider to value 1 */

In JN5189_Project3.c: SWO initial code grabbing from Serial_SwoInit() at serial_port_swo.c (to make it simple).

static bool s_SwoInit()
{
    serial_port_swo_config_t swoConfig = {
        .clockRate =  3000000UL,
        .baudRate  =  3000000UL,
        .port      = 1ul,
        .protocol  = kSerialManager_SwoProtocolNrz,
    };

    uint32_t prescaler = swoConfig.clockRate / swoConfig.baudRate - 1U;

    /* enable the ITM and DWT units */
    CoreDebug->DEMCR = CoreDebug_DEMCR_TRCENA_Msk;

    if ((CoreDebug->DEMCR & CoreDebug_DEMCR_TRCENA_Msk) == 0U)
    {
        return false;
    }

    /* Lock access */
    ITM->LAR = 0xC5ACCE55U;
    /* Disable ITM */
    ITM->TER &= ~(1U << swoConfig.port);
    ITM->TCR = 0U;
    /* select SWO encoding protocol */
    TPI->SPPR = swoConfig.protocol;
    /* select asynchronous clock prescaler */
    TPI->ACPR = prescaler & 0xFFFFU;
    /* allow unprivilege access */
    ITM->TPR = 0U;
    /* enable ITM */
    ITM->TCR = ITM_TCR_ITMENA_Msk | ITM_TCR_SYNCENA_Msk
               | ITM_TCR_TraceBusID_Msk
               | ITM_TCR_SWOENA_Msk | ITM_TCR_DWTENA_Msk;
    /* enable the port bits */
    ITM->TER = swoConfig.port;

    return true;
}

The code above works by the following procedure:

1. start debugger with holding RESET button of JN5189.
2. when the first error dialogue is shown, press [OK] button and release RESET button at the same time. (without this procedure, the linking establishment fails so frequently...)
3. At [SWO Trace Config] tab, go to [Configuration] tab and press [Change] button of target clock speed and set 3MHz (as set above) and press [OK] button.
4. Then go to [Status] tab and check if [probe back end] turns green. If not, linking is failed.

The first question is that it's very hard for me to establish link of SWO. The procedure 2. is too tricky. I don't think it's normal behavior but has something missed.

The second question is [SWO ITM Console] message output. Of course the SWO link is established well by seeing other screen like [SWO Interrupts]. 

The my sample code works as below:

• on SysTick_Handler() running at 1000Khz, it outputs '.' to USART message and ITM console every 128 ticks.
• type 'a' to output a longer message using PRINTF() call (same message to USART as well).
• type 'b' to output a longer message using _write() call (same message to USART as well).

My code does not output correct messages via PRINTF() call, but _write() works. The PRINTF is defined as printf() in the code and the printf() should call _write() in the final. However, only corrupted bytes are output. I tried using PUTCHAR(), but it's also corrupted.

The correct output is done by:

• The low level access, _write() or ITM_SendChar()
• By building with REDLIB

I guess there is something wrong at buffering part in printf() or putchar(). But no idea what is wrong.

Thanks in advance!

[usaygo]

Hello Ricardo,

Thanks for your comment.

Yes, I've read SWO Trace Guide and confirmed it worked. My problem is not the standard procedure. As in my report, the problem is that it's not initialized properly by some reason (might be initialization process when going into debug mode?). Anyway, if you have some update or information, it would be very welcome. So far, I have a workaround to make it work. It's not urgent matter. 

My report describes the other thing. NanoLib printf/putchar works unstable. By seeing its behavior, it seems due to buffering mechanism of internal library. I'm planning to use C++ as well, so Redlib is not my option. (for just printf, I'm using different code base, so it's not a big problem. Just for your information.

> is that the usage of semihost is not recommended to use with our wireless products.

I'm new for ARM Cortex-M4. I've read about smihost which has much of overhead while debugging. So I understand that semihost printf() is not recommended for many realtime applications. But by hearing about SWO by information generally spread, it's lower overhead and less affective to the target device. So I thought that it's nice for wireless applications. Indeed SWO trace output takes less time even if it's blocking output and also it has attractive feature (monitoring variables, call functions, interrupts, etc..). I see UART printf() is still one of the best tracing method, but I guess SWO is completing in some case.

Or as you commented, semihost makes impact to wireless task even SWO is only used??? Even if I don't stop firmware by debugger while testing, is there any implicit impact on firmware behavior?

I'm a bit confusing. Comments are very welcome. Thanks!

[Ricardo_Zamora]

Hi,

Hope you are doing well. Can you refer to sections 16.5.6 and 16.5.7 of the MCUXpresso IDE User Guide and to section 3 of the MCUXpresso IDE SWO Trace Guide?

One important remark, is that the usage of semihost is not recommended to use with our wireless products. It's highly encouraged to use the UART method, because the interrupts used by the Semihost can have an impact on the wireless stack, preventing your code from running as intended.

Also, this community post (How To Use SWO Trace on MCUXpresso IDE) might be helpful.

Regards,

Ricardo