Page 4 of 5
Re: Events for serial driver transmission completion
Posted: Fri Aug 25, 2017 2:54 pm
by Giovanni
I am watching this, no problems.
I need to test the scenario myself.
Giovanni
Re: Events for serial driver transmission completion
Posted: Mon Aug 28, 2017 3:51 pm
by Giovanni
Hi,
I have committed a tentative fix in trunk (subversion) for the USARTv1 driver (I assume it is this one since your device is not specified).
I verified that the driver indeed generated a spurious event after sdStart(), it does no more happen in the fixed version. The change was trickier than I expected, the TC flag is set after reset and, apparently, it is impossible to reset it in the SR register manually.
The bit is now reset by writing the data register and ignored when a transmission has not been started.
I have to verify if USARTv2 is also affected but probably not.
Giovanni
Re: Events for serial driver transmission completion
Posted: Mon Aug 28, 2017 7:32 pm
by Raul
Hi Giovanni,
Thanks, I'll run against the fix tomorrow. It makes sense to check for TCIE and empty buffer for completeness.
Out of interest, what does it cause the reset that sets TC in your set up? Did you have to pump data into the uart to replicate it?
Raul
Re: Events for serial driver transmission completion
Posted: Mon Aug 28, 2017 9:16 pm
by Giovanni
Replicate was easy, just call sdStart() and it happened... the fix was less obvious.
Giovanni
Re: Events for serial driver transmission completion
Posted: Tue Aug 29, 2017 10:19 am
by FXCoder
Hi Giovanni,
Raul said he was using an F407 in an earlier post.
What board did you test on?
I've tested with an F413 and so far could not get TE event issue.
Bob
Re: Events for serial driver transmission completion
Posted: Tue Aug 29, 2017 1:32 pm
by Giovanni
I tested on an F407 too, I missed where he specified it.
Giovanni
Re: Events for serial driver transmission completion
Posted: Tue Aug 29, 2017 5:30 pm
by Raul
Interesting that it just happened in your setup. In my case if I isolate the F407 from the uart bus during start up I don't see the problem, this use case is closer to Bob's and I couldn't replicate with a minimalist test based I run with just a discovery board, so I deduced that it was because of the initial presence of data in my case.
The fix works well, it resolves the problematic case. I noticed you removed u->SR = ~USART_SR_TC; Shouldn't you still clear it explicitly?
Re: Events for serial driver transmission completion
Posted: Tue Aug 29, 2017 8:30 pm
by Giovanni
The fix was letting the USART clear TC on data write automatically, not explicitly, explicit clearing is problematic apparently.
Giovanni
Re: Events for serial driver transmission completion
Posted: Wed Aug 30, 2017 1:22 pm
by Raul
I think what made the difference was to check for TCIE, to be clear the following works too:
Code: Select all
/* Physical transmission end.*/
if ((cr1 & USART_CR1_TCIE) && (sr & USART_SR_TC)) {
osalSysLockFromISR();
if (oqIsEmptyI(&sdp->oqueue)) {
chnAddFlagsI(sdp, CHN_TRANSMISSION_END);
u->CR1 = cr1 & ~USART_CR1_TCIE;
u->SR = ~USART_SR_TC;
}
osalSysUnlockFromISR();
}
Reading further ST's reference manual states that TC is also cleared by a software sequence (a read from the USART_SR register followed by a write to the USART_DR register). That seems to happen when a transmission interrupt is enabled and the first byte is consumed from the queue. So, I believe that's the reason why clearing TC explicitly is not extrictly necessary.
Re: Events for serial driver transmission completion
Posted: Wed Aug 30, 2017 3:01 pm
by FXCoder
Interesting that the behavior of USART at start is still not consistent between the 3 x test results.
1. I don't see anything using the sequence Raul described.
This is with TX and RX mapped out to GPIO but not connected to anything on an F413.
2. This is the same result Raul gets when TX & RX is mapped out to GPIO but not connected to anything on an F407.
3. Yet Giovanni gets the erroneous event from TC on an F407 (assuming this was with GPIO mapped out?)
Could be different revs of F407 silicon I guess?
Perhaps a more reliable way of dealing with peripheral enable would be to add rccReset to the end of each bus rccEnable macro?
If done in the common rccEnable macro for each bus it would apply to all peripheral enables.
Pretty much what was discussed a little earlier in this thread.
Thoughts?