Events for serial driver transmission completion

[Giovanni]

I am watching this, no problems.

I need to test the scenario myself.

Giovanni

[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

[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

[Giovanni]

Replicate was easy, just call sdStart() and it happened... the fix was less obvious.

Giovanni

[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

[Giovanni]

I tested on an F407 too, I missed where he specified it.

Giovanni

[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?

[Giovanni]

The fix was letting the USART clear TC on data write automatically, not explicitly, explicit clearing is problematic apparently.

Giovanni

[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.

[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?