High rate serial logging

[ohtap]

Hi,

I'm trying to log data over a serial connection using the DK52. 

The data is coming from a sensor at about 2KHz at a size of 30 bytes per sample, so 60KBps.

I've set the Baudrate to 912600 and enabled HWFC. Using NRF_LOG_RAW_INFO to print the data into a PuTTY terminal configured the same way.

The issue is that the data printed isn't up to speed with what is expected. Between 10 and 100 characters are being printed per batch of 240.

Is there any special configuration that has to be set to log at a high rate?

Thanks

[Kenneth]

Hi,

Have you looked at a logic analyzer trace when transmitting 240bytes only?

This can identify if the problem is the USB to UART bridge (you may try a FTDI chip if possible) or if the problem is the UART driver on the nRF52.

Best regards,
Kenneth

[ohtap]

Hi,

I've connected Pin 6 (TX) to a logic analyzer.

When not transmitting the channel is clean without any noticeable noise.

The first 240 characters are always printed correctly on the terminal.

I suspect this has something to do with bad configuration on my part...

I've integrated this as part of the ATT_MTU Throughput example , so I'm relying mostly on the configuration used in the example, with the Baudrate set now at 1M on both the sdk_config.h and on the terminal.

[Kenneth]

Is there any way you can share with me a screenshot of what it looks like when it fails on the logic analyzer? I want to see if bytes are skipped, corrupted etc.

Best regards,
Kenneth

[ohtap]

I'm attaching screenshots in various zoom levels. There are periods with gaps where the channel is "static" but should contain data transmissions.

[Kenneth]

Can you try to disable HWFC and/or also record the RTC/CTS lines?

Best regards,
Kenneth

[ohtap]

The same behavior appears when HWFC is disabled.

Channel 1 for CTS, channel 2 for TX, 3 for RTS.

[Kenneth]

I assume that a problem may be that it is difficult in hardware to generate an accurate 912600baud from the internal clock (not easily to divide), likely the baud rate will be off (with a few %), though this should potentially corrupt bytes, not skip bytes. In any case it would be better if you could use 10000000baud, this should be accurate.

I tried the \examples\temperature from SDKv15 by setting it to to max baudrate (1M) in sdk_config.h, and removed the nrf_delay_ms(500) in the while loop. I also manually started the HFCLK to have an accurate clock by:

    NRF_CLOCK->EVENTS_HFCLKSTARTED = 0;
    NRF_CLOCK->TASKS_HFCLKSTART = 1;
    while(NRF_CLOCK->EVENTS_HFCLKSTARTED == 0);
    NRF_CLOCK->EVENTS_HFCLKSTARTED = 0;

This seems to print at least the following in a loop without any issue:

Maybe you can test it for comparison?