Page 1 of 1

Issue with UART driver

Posted: Tue Jan 09, 2018 2:08 pm
by 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?

Re: Issue with UART driver

Posted: Tue Jan 09, 2018 2:23 pm
by 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

Re: Issue with UART driver

Posted: Tue Jan 09, 2018 4:44 pm
by 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?

Re: Issue with UART driver

Posted: Tue Jan 09, 2018 4:53 pm
by Giovanni
Correct, it is unbuffered.

Giovanni

Re: Issue with UART driver

Posted: Tue Jan 09, 2018 5:16 pm
by 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;

Re: Issue with UART driver

Posted: Tue Jan 09, 2018 6:36 pm
by Giovanni
I am not sure what that code snipped is supposed to do but it looks suspicious.

Giovanni

Re: Issue with UART driver

Posted: Tue Jan 09, 2018 7:18 pm
by 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.

Re: Issue with UART driver

Posted: Thu Jan 11, 2018 8:52 pm
by 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...

Re: Issue with UART driver

Posted: Thu Jan 11, 2018 9:05 pm
by Giovanni
If you are using an F7 make sure to read this: http://www.chibios.org/dokuwiki/doku.ph ... _dma_guide

Giovanni

Re: Issue with UART driver

Posted: Fri Jan 12, 2018 12:30 pm
by 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... ;) )