TI E2E Community
C2000 32-bit Microcontrollers Forum
BRKDT on F28335
Hello,I'm facing something strange.I use the three SCI on my MCU with good efficiency except in one case.Time to time, a break occur "SCI receiver data line (SCIRXD) remains continuously low for at least ten bits".The ISR reset the SCI and it's OK. But sometime, the SCI stays stuck. (The break could be far far longer than ten bits).This kind of break is not normal (hardware problems) but normaly, the SCI should manage it ?Thank you for your help.
If the receiver line of C2000 SCI is being held low continuously for 10 bits or more after a missing stop bit, SCI gets a break condition and will hit error ISR. If the receiver line is not pulled high even after the ISR clears the BRKDT with a reset, SCI will again hit the break condition and hence ends up in error ISR repeatedly. Hence, it is up to the application hardware to keep the receiver line high when there is no communication.
Thanks and regards,Vamsi
Thank you for your quick answer.
That you explain is exactly what I was expecting, and it occurs the main time.
But time to time, the SCI blocks and stop firing interrupt.
What I want to know is: is it a normal reaction facing to an abnormal hardware situtation or there is something else ?
Are you saying that at times SCI is not firing the interrupt when a valid character is received OR when the break happens?
Please note that once a breakdetect occurs, no more characters will be loaded in to receive buffer until SCI is reset. May be the valid character is being sent by host even before the SCI was reset to bring it out of BRKDT condition.
It's exactly the problem, during the long "break" several interrupts are fired, until the "break" stop.
But some time the SCI block before the "break" stop. And not more interrupt is fired (valid characters or break).
Thank you en best regards,
From your reply, looks like you exactly dont know when the break or valid data is being sent from host.
It might be that just after the SCI reset in the ISR, a valid data did get received instead of a break but the FIFO levels might not have matched yet to generate an interrupt. Hence you might not be receiving any interrupt. Are you sure that the RX line is always pulled low by the host when there is no data? OR it sometimes gets pulled high and sometimes gets pulled low when there is no data transfer?
Reason I am asking is that there might be a chance of valid data occurence as I mentioned above and then the line is being pulled high later and hence did not see an interrupt because of not matching FIFO levels yet. Are you using FIFO?
Thanks and regards,Vamsi
The sequence is following:
The RX line is pulled low for almost 200ms then pulled high. The real transmition starts few hundreds ms after.
Thank you for your help
You did not mention whether you are using FIFO or not?
If yes, what is the value that you set for RXFFIL bits? Now that you confirmed that the RX line is pulled up after some time, as I explained, it might be that the valid data did come in to FIFO but did not match the level bits and hence did not get an interrupt. Are you sure that the host sent valid data and that host sent enough characters such that the RXFFIL bits would generate an interrupt?
Why dont you disable the RX for the duration when the line is pulled low?
Sorry for the delai, I am out of office for 2 weeks.
For your question, yes I use the fifo, and most of the time all work fine.
But after the long "break" has occured, the data sent by the host are valid (verified by a scope) but the SCI do not detect these datas (the fifo is empty).
The only way to restart de reception is reseting the SCI (by the reset bit of the control register)
Could you set the RXFIFO level match bits (RXFFIL) to 1 and see whether you are able to receive data or not?
I will try when I will be back to my office in 1 week.
Hi Vamsi,I think, I have found the problem.We used the FIFO, but the bit "RXERRINTENA" of the SCICTL1 register was not set.We made a mix, in the error management, between the two modes (with or without FIFO).In fact I wonder how it could work (the system was running perfectly until we made hardware modifications).One more little question: The FIFO fire and interrupt when RXFFST match RXFFIL. But, if the flow of data stop, and few bytes stay in the FIFO, what is happening? For example, an answer frame, made with 18 bytes is received.If the FIFO is set with RXFFIL=8, it will fire 2 interrupts (16 bytes), so 2 bytes will stay in the FIFO?I noticed that it is not the case, (maybe a timeout?), but I did not find, in the SCI reference guide, a description of this.Thank you for kindnessBest RegardsRobert
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.