SWO signal inversion bug

RE: SWO signal inversion bug

NickT — Thu, 02 May 2019 08:09:50 GMT

After much headscratching - another support site gave me this answer

"When (Cortex M-series) target enters true low power mode (in the absence of debug connection) due to a sleep event and there is data in the ITM/TPIU that has not been flushed, then the data stream gets mangled with garbage due to what appears to be clock gating/changes when core transitions to sleep."

After I disabled the sd_app_evt_wait() call in our project the SWO is 100% reliable as a uart output.

With the debugger connected, the core does not transition to sleep so SWO functions correctly even with the call to sd_app_event_wait()

As far as I can tell, there are no flags to say when the last character has been flushed from the FIFO, so we cannot hold off the call to sleep until all the characters have been sent.

Moving on...

RE: SWO signal inversion bug

Edvin — Thu, 02 May 2019 07:41:39 GMT

Hello Nick.

Is it possible to send a project that replicates this?

Are you sure that the signal is inverted, and that it isn't the frequency that is off? Have you tried to scope the signal?

I would still recommend that you try out the UART with only the TX pin, if this is for debugging/logging features only.

RE: SWO signal inversion bug

NickT — Wed, 01 May 2019 08:14:43 GMT

Thanks Bill,

I had managed to access that - would have been nice if Nordic pointed to it. I have now got a handle on most of how the SWO is supposed to be setup, although there are a couple of registers that are not well explained even in the ARM documentation.

e.g. DWT control, and "Formatter and Flush Control"

But no amount of tinkering has yet figured out why this works with the debugger connected (i.e. immediately after programming) but corrupts after power-cycling the target. If we ever get to the bottom of this I'll put it up on this board.

RE: SWO signal inversion bug

NickT — Tue, 30 Apr 2019 11:50:12 GMT

More information - there is a possibility that the TPIU gets corrupted when the core goes to low power mode.

Is there a way to configure the SDK so that sd_app_evt_wait does not go to low-power modes, for debugging purposes?

Thanks

RE: SWO signal inversion bug

wpaul — Mon, 29 Apr 2019 16:56:39 GMT

[quote userid="78841" url="~/f/nordic-q-a/45955/swo-signal-inversion-bug/181253"][/quote]

but...

the section on the ITM states this..."Other registers are described in the ARM^®v7-M Architectural Reference Manual."

And that document is "only available to registered ARM customers"...

Just FYI, that manual seems to be available for download here:

https://static.docs.arm.com/ddi0403/eb/DDI0403E_B_armv7m_arm.pdf

Don't know if this helps with your problem though.

-Bill

RE: SWO signal inversion bug

NickT — Mon, 29 Apr 2019 13:32:48 GMT

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

RE: SWO signal inversion bug

Edvin — Tue, 23 Apr 2019 06:38:32 GMT

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

RE: SWO signal inversion bug

NickT — Wed, 17 Apr 2019 10:14:00 GMT

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?

RE: SWO signal inversion bug

Edvin — Tue, 16 Apr 2019 08:38:58 GMT

[quote user="NickT"]I don't believe RTT is available without Segger...but I may be wrong[/quote]

That is correct. It doesn't look like it supports 57600Hz, if you look in the nrf52_bitfields.h on line 1228-1233.

[quote user="NickT"]The previous engineer added the SWO_init code to the product to get a "uart" data stream available for application monitoring, even when there is no debugger connected.[/quote]

This should still be possible. You can use the UART to output data even if you only have 1 pin. You can use this as TX and not initialize the RX pin.

If you look at the ble_app_uart example from the SDK, in the uart_init() function, try to comment out the pins that aren't used:

static void uart_init(void)
{
    uint32_t                     err_code;
    app_uart_comm_params_t const comm_params =
    {
        //.rx_pin_no    = RX_PIN_NUMBER,
        .tx_pin_no    = TX_PIN_NUMBER,
        //.rts_pin_no   = RTS_PIN_NUMBER,
        //.cts_pin_no   = CTS_PIN_NUMBER,
        .flow_control = APP_UART_FLOW_CONTROL_DISABLED,
        .use_parity   = false,
#if defined (UART_PRESENT)
        .baud_rate    = NRF_UART_BAUDRATE_115200
#else
        .baud_rate    = NRF_UARTE_BAUDRATE_115200
#endif
    };

    APP_UART_FIFO_INIT(&comm_params,
                       UART_RX_BUF_SIZE,
                       UART_TX_BUF_SIZE,
                       uart_event_handle,
                       APP_IRQ_PRIORITY_LOWEST,
                       err_code);
    APP_ERROR_CHECK(err_code);
}

I tested this and it throws a framing error in the UART event handler. Remember to comment out this:

        case APP_UART_COMMUNICATION_ERROR:
            //APP_ERROR_HANDLER(p_event->data.error_communication);
            break;

It is just tellling you that you have a framing error on the RX, which is not initialized, so that shouldn't be a concern.

Using the UART, you can also set the baudrate you desire:

.baud_rate = NRF_UART_BAUDRATE_57600

Best regards,

Edvin

RE: SWO signal inversion bug

NickT — Fri, 12 Apr 2019 09:45:15 GMT

Edvin,

The previous engineer added the SWO_init code to the product to get a "uart" data stream available for application monitoring, even when there is no debugger connected.

I don't believe RTT is available without Segger...but I may be wrong

Rick's code seems to assume that SWO can be run at 4MHz, not 57600, but that might be a simple matter of setting the pre-scalar.

RE: SWO signal inversion bug

Edvin — Thu, 11 Apr 2019 15:37:46 GMT

[quote user="NickT"]it is used for runtime logging[/quote]

In the finished application, or for debugging? Have you considered using the RTT backend for the logger?

Did you try Rick Chung's implementation (step 1-4) in the post that you linked to? Does that behave the same way as your implementation? (flipping the signal?)

RE: SWO signal inversion bug

NickT — Wed, 10 Apr 2019 08:56:33 GMT

Hi Edvin,

Yes - the project uses pin 18 as SWO. it is used for runtime logging, and there is no room on board for a uart connection.

Also, I found a CMSIS function ITM_Sendchar in core_cm4.h that does 8-bit writes to ITM->PORT[].u8 , so I am less worried about that now.

RE: SWO signal inversion bug

NickT — Wed, 10 Apr 2019 08:36:15 GMT

Hi again,

I am finding some of the information for the ITM in the ARM infocenter.

http://infocenter.arm.com/help/index.jsp

but...

the section on the ITM states this..."Other registers are described in the ARM^®v7-M Architectural Reference Manual."

And that document is "only available to registered ARM customers"...

Which perhaps explains why I cannot find out what the code is supposed to do. :roll:

RE: SWO signal inversion bug

Edvin — Wed, 10 Apr 2019 07:31:24 GMT

Oh. Sorry. I didn't test the link. From the link address, it looks like it is here:

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52832.ps.v1.1%2Fclock.html&cp=2_1_0_18_2_9&anchor=register.TRACECONFIG

I have not tested, but it looks like the SWO pin, if you use serial, and not parallel, is P0.18. Is that the one you are using?

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52832.ps.v1.1%2Fpin.html&cp=2_1_0_3&anchor=pin_assign

Are you sure SWO is what you really are looking at using? It is typically a debugging tool (If you have a debugger that is connected to that pin).

Maybe what you really want to is to enable logging? UART?

Best regards,

Edvin

RE: SWO signal inversion bug

NickT — Tue, 09 Apr 2019 13:56:00 GMT

Hi Edvin,

Thanks for the prompt response.

I am picking up on a GCC project which is in pre-production, so don't want to muck about with the code until I am sure. Not sure if this debugging software came from an appnote/example, or if it was invented locally.

The link from that previous thread throws a 404 error here . If the documentation exists, can you give me a pointer to the reference manual with register definitions for ITM please?

The bit flip appears on the pin of the Laird BL652 SA01, I don't think that has segger OB.

Also, I noticed that the implementation uses

ITM->PORT[0U].u8 = (uint8_t)currentChar;

And it occurred to me that ITM writes might be 32 bit only, (there is a hint of that in the Arm Docs [CoreSight Components Technical Reference Manual 12.2.2] so maybe the uart mode leaves a bit dangling in the upper byte of the lower word?

If you can confirm if it is safe to use 8-bit writes to ITM->port it would at least eliminate one possible cause of error.

RE: SWO signal inversion bug

Edvin — Tue, 09 Apr 2019 12:55:50 GMT

Hello,

Yes, we had some problems with the Doclib's nRF52832 section. But all HW related information on infocenter is still the same, so that part isn't really outdated.

I haven't tested your implementation, but I did try the one you linked to (this one) a couple of times earlier, and that worked. Do you get the same error with that implementation?

Where do you measure that the bit is flipping? Do you measure the pin from the nRF, or from the On Board (OB) Segger chip?

Best regards,

Edvin