[DONE] Serial port losing data when several threads are acti

[trepidacious]

Hi Giovanni,

It really is the weirdest bug - I had the same issue with it, where it only occurs for some compiler settings and can be turned on and off by (apparently) unrelated code, or changing optimisation settings. For example it first cropped up for me when adding/removing the event code that shouldn't have any effect on the serial transmission/reception itself. In the project I sent, it only happens for some optimisation levels.

I'll give that code a go and let you know what happens

Ben.

[trepidacious]

Hi Giovanni,

I just tried that code (I also disabled the MEMS thread since the only board I have available is missing the MEMS IC), and it seems completely reliable. I also tried -O1 for luck, still fine. I think to get it to happen again you might have to go back to the exact failing code, since I found that changing anything (even just to debug) could cause it to fail more, less, or not at all

Ben.

[Giovanni]

OK, so now we have two versions, the one you sent that fails and this one that never fails...

And the difference is... [insert solution here]

I need to test more.

Giovanni

[Giovanni]

Hi,

I think I found the trigger of the problem:
1) I always get the problem when CH_DBG_SYSTEM_STATE_CHECK is TRUE (both my code and yours).
2) When CH_DBG_SYSTEM_STATE_CHECK is FALSE the problem is never triggered.
3) The other debug options do not affect anything.

Ben, could you confirm this on your side?

Giovanni

[Giovanni]

Update,

I tried the same code on an STM32F3 and the problem never appears, the difference is in the serial driver USARTv1 for the F4 and USARTv2 for the F3.
It is probably something in the serial driver, I am still testing.

Giovanni

[trepidacious]

Hi Giovanni,

I recompiled my original failing project with just the CH_DBG_SYSTEM_STATE_CHECK disabled, and this fixes things for me (I also double checked that with this enabled, I still get failures). Please let me know if there's anything else I can check.

Ben.

[Giovanni]

This is very strange, I can't simply accept a workaround, there is something going on.

So far we know:
- It does not happen disabling the checker but probably this is not the cause, just a trigger.
- It does not happen without optimizations.
- In does not happen on the F3.

I noticed that when the timeout happens the lost character is present in the USART data register (so it has been transmitted) but the RX interrupt is not triggered, the RXNE bit in the SR is zero. This is the weird part.

Giovanni

[DrunkenDonkey]

Following the topic with great interest, the "And the difference is... [insert solution here]" line cracked me

For what is worth, had serial data loss on STM32L too, if that helps narrowing it.

[Giovanni]

Hi,

This could confirm that it is related to the USARTv1 driver, the L1 uses the same driver of the F4. Only F0 and F3 use USARTv2.

Giovanni

[trepidacious]

I ran into another slight issue with the USART the other day, it also seems to be to do with odd behaviour of the USART peripheral registers so I guess there's a small chance it might be related?

When using the USART driver for 1-wire, it's necessary to reconfigure the port using uartStop and uartStart, for example to change the speed. If you call uartStartSend immediately after starting the driver, there is a delay of slightly more than the time needed to send one byte at the new speed, before the first byte is actually sent. So for example, if you stop the driver, restart it at 9600, then send a byte, you can see a delay of about 1ms before the byte is actually sent (which also takes about 1ms). For higher speeds the delay is correspondingly less. Subsequent bytes in the buffer send without a gap as expected, and subsequent uartStartSend calls give no delay before the data appears on the wire.

If you add a sleep between uartStart and uartStartSend, this reduces the delay between calling uartStartSend and seeing the data on the wire; if the sleep is longer than "one byte" in time, then there is no delay between calling uartStartSend and seeing the data.

I haven't tried the same thing with the Serial driver, it may well do the same thing.

I ran into someone on IRC, stm32 channel, who had had the same problem using their own driver, outside ChibiOS, and had found a workaround. I haven't looked at the peripheral in detail so I'll just relay it directly:

I think this fixed it for me- while ((USART2->ISR & USART_ISR_TC) == 0); instead of USART_ISR_TXE

I don't know if this applies to ChibiOS, hopefully it is of some help/interest though.