- Silicon Labs Community
- Welcome and Announcements
- Silicon Labs Knowledge Base
- 8-bit MCU
- 32-bit MCU
- Bluetooth / Wi-Fi
- Other Products Category
- Optical/RH/Temp Sensor
- Other Products
- Hardware and Software Tools
- Simplicity Studio and Software
- General Discussions and Suggestions
- Chinese Forum
- Software Libraries
- Development Kits
- Reference Designs
- Third Party Tools
- White Papers
- Official Blog of Silicon Labs
- Chinese Blog
05-30-2017 07:17 AM
I am trying to get detect physical disconnects through a pull down resistor on the EFM32 RX pin and a serial 'break condition' (it is a detachable device and the recommended way to detect its presence).
During serial communication, the uart detects this as a single framing error (as expected), however from that point on no further bytes are received, and the dma transaction (and also the UARTDRV_Receive transaction) never finish.
There seems to be code in uartdrv for handling framing errors, however this is only checked after the transaction completes.
How do I get a 'break condition' to stop the transaction?
I currently use an interrupt that cancels the transfer, but that doesn't seem quite clean, especially as there is some functionality for framing errors implemented in uartdrv, and i'm also not quite sure what will happen if the disconnect occurs on the last byte of the sequence. Furthermore, as I now use the RX interrupt anyway and have added quite some glue code, it almost makes more sense to simple write my own interrupt based uart driver.
There also seems to be a bug in uartdrv: If during a single (large) transaction both a framing error and a parity error occur, ReceiveDmaComplete only clears USART_IFC_FERR, but not USART_IFC_PERR.
05-30-2017 11:07 AM
In my personal experience, UARTDRV is far from stable and I've had a bunch of difficulties with it in my own projects. (I even created patches for it to fix my use case, roughly a year ago, but they still haven't been included in the SDK.)
Can you please share more details about your design? Ie. is that peripheral only connected to the UART RX pin? Is there any other way to detect its presence? What kind of device is it, anyway?
If it really is only connected to the RX pin, and you have no other way to detect its detach, then I'd simply write an UART interrupt handler for the framing an/on parity error and I'd call UARTDRV_Abort in that interrupt handler. Since UARTDRV has no interrupt handlers (at least it didn't, last time I checked), it can't really react to these kind of errors and you don't really have a better way of doing this.
To be honest, my experience with UARTDRV has convinced me that UARTDRV is trying to solve the wrong problems (or at least, not the problems I have) and that I, too, will eventually need to write my own (LE)UART+DMA driver. (The main pain points for me are the lack of support for a bunch of LEUART features and lack of half-duplex support.)
Perhaps eventually Silabs will take the time and effort to make a decent (LE)U(S)ART driver.
06-01-2017 01:21 AM
Thank you for your reply.
A sensor module with a 4 pin connector (gnd, tx, rx, 3v3) connects with a display unit (with a giant gecko). The display unit has a pulldown on its rx.
As soon as the module connects and powers (and is ready for communication), its tx signal becomes high. This is catched with a gpio interrupt, after which the giant gecko’s uart gets enabled. The sensor module responds kind of slow (during a calibration procedure it can take up to 3 minutes until a reply arrives).
This means timeouts (a timer calling uart_abort) can take quite some time before kicking in. Therefore a break condition has been previously successfully used (with TI µC) to detect disconnects with this sensor module.
It saddens me to hear about your negative experience with UARTDRV and it makes me wonder why they've even included it in the SDK in the first place.
Some other things I noticed:
- UARTDRV isn't aware of SLEEPDRV...
- UARTDRV_Transmit is missing a const in its signature. Some of the commands I send to the serial module are stored in flash, and I needed a const cast before I was able to transmit these commands.
06-01-2017 08:58 AM
> UARTDRV isn't aware of SLEEPDRV...
I believe it would be enough for DMADRV to be aware of SLEEPDRV, not sure if this is the case or not. Anyway, neither UART nor the DMA can work at anything but EM0 and EM1, so it shouldn't be hard to add support.
> UARTDRV_Transmit is missing a const in its signature
Yes, that bothers me too.