Issue with UART driver

[josesimoes]

I'm having issues with the UART output using the UART driver.

Everything seems to be properly setup as I can actually see output from the UART.
The issue is with the content. The content is supposed to be different on each output.
I have a TX buffer that is loaded with wathever I want to output. I'm using SWO output to double check that the buffer content is the expected.

Code: Select all

uartStartSend(&UARTD6, length, (uint8_t*)txRingBuffer);

The buffer pointer is always the same, length varies.

With the above here's an example of the output:
1001 hello from nanoFramework
1001 hello from nanoFramework
1001 hello from nanoFramework
1001 hello from nanoFramework
1001 hello from nanoFramework
1001 hello from nanoFramework
1001 hello from nanoFramework
1001 hello from nanoFramework
1001 hello from nanoFramework
1001 hello from nanoFramework
1001 hello from nanoFramework
1001 hello from nanoFramework
1001 hello from nanoFramework
1021 hello from nanoFramework
1021 hello from nanoFramework
1021 hello from nanoFramework
1021 hello from nanoFramework



If I add this before the above call:

Code: Select all

uartStartSend(&UARTD6, 2, "\r\n");

this is what I get on the output:
1001 hello from nanoFramework
1003 hello from nanoFramework
1004 hello from nanoFramework
1004 hello from nanoFramework
1004 hello from nanoFramework
1004 hello from nanoFramework
1008 hello from nanoFramework
1008 hello from nanoFramework
1008 hello from nanoFramework
1011 hello from nanoFramework
1012 hello from nanoFramework
1013 hello from nanoFramework
1014 hello from nanoFramework
1015 hello from nanoFramework
1015 hello from nanoFramework
1015 hello from nanoFramework
1018 hello from nanoFramework
1019 hello from nanoFramework
1019 hello from nanoFramework
1019 hello from nanoFramework
1022 hello from nanoFramework

From the look of it, it seems that the DMA transaction is not actually started or updated and the same content is tx over and over.
When changing the pointer and content (by adding that dummy CR+LF on a fixed string) the DMA is "updated" almost everytime.

Could it be that something is missing in the DMA setup that is not making what's supposed to (resetting? restarting?) when the pointer (and/or) pointer + length are exactly the same has they were on the previous call?

[Giovanni]

Hi,

uartStartSend() is:
1) Non blocking, it returns immediately, the transmissions proceeds in parallel.
2) Not buffered, if you change the buffer data after the function returned it will print the new content.

Use uartSendTimeout() instead.

Giovanni

[josesimoes]

Understood all that.

Forgot to mention that I'm blocking the write of the new buffer content until the previous one is Txed.
Also if the contents were being overwritten I would be seeing the newest content not an oldest one, right?

[Giovanni]

Correct, it is unbuffered.

Giovanni

[josesimoes]

No doubt it's unbuffered I'm providing the buffer in my code.

I've just replaced uartSend() with uartSendTimeout(). The result is the same: I keep seeing old data...

I've looked for the UART test case in the source code.
If I'm not mistaken it's here: testhal\STM32\STM32F4xx\UART

Using that code won't catch the use case I'm describing because the message being Txed is always the same.

Suggest changing the uartStartSend there with the snippet bellow to test this (need to declare the index as int first, of course):

Code: Select all

uartStartSend(&UARTD2, 8, &message[index++]);
if(index == 8) index = 0;

[Giovanni]

I am not sure what that code snipped is supposed to do but it looks suspicious.

Giovanni

[josesimoes]

Basically it "moves" the message buffer so the output is not the same on each iteration.
The goal is to test continuous write operations to the UART with different content.
Using the same output over and over can't test the situation I'm describing that motivated my original post.

[josesimoes]

I've been trying to figure out the root cause of this.
A couple of questions:

1) isn't the uart_lld_start_send missing a dmaStreamDisable(uartp->dmatx);?
All other functions there that set DMA memory and transaction are disabling the stream before those calls. This on isn't.

2) For F7 (which is the one I'm working right now) shoudln't __DSB() be added when setting the DMA addreses? Maybe the addresses are wrongly set because of caching...

[Giovanni]

If you are using an F7 make sure to read this: http://www.chibios.org/dokuwiki/doku.ph ... _dma_guide

Giovanni

[josesimoes]

Giovanni that was it!
Now I'm seeing the expected data in and out the UART.

(whish I had made the right questions sooner... )