serial errOverRun
Posted: Thu Feb 02, 2017 10:21 am
Hello,
I'm working with Chibios 16.1.6 on MPC5748g EVB with powerpc-eabivle-gcc from Freescale S32 Design Studio 1.1
My MPC5 port is almost identical with the SPC5 that is in chibios - I just took startup.s code from Freescale templates and had to make some fixes for freescale gcc version.
My application is reading data from serial port LIN2 with the following code:
uint8_t nextByte;
while(true) {
sdRead(sd, (uint8_t*)&nextByte, 1);
if (sd->errOverRun || sd->errFraming || sd->errBreak) {
while (1) ; <- block to check it in the debugger
}
if (!updateInput(nextByte)) {
At speed of 115200 it works fine. However, at speed of 1Mb/s it starts dropping bytes and the errOverRun counter goes up - BOI interrupt is triggered. I have tried all versions of read - sdRead, chnRead, sdReadTimeout, chnReadTimeout - it always drops data at higher speeds. Can you please advice how to solve the problem?
Sorry if my second question is stupid. Why do we have to disable the interrupts in iqReadTimeout(...) before putting the caller thread to sleep with osalThreadEnqueueTimeoutS(...). Don't we miss the UART interrupt that way?
I'm working with Chibios 16.1.6 on MPC5748g EVB with powerpc-eabivle-gcc from Freescale S32 Design Studio 1.1
My MPC5 port is almost identical with the SPC5 that is in chibios - I just took startup.s code from Freescale templates and had to make some fixes for freescale gcc version.
My application is reading data from serial port LIN2 with the following code:
uint8_t nextByte;
while(true) {
sdRead(sd, (uint8_t*)&nextByte, 1);
if (sd->errOverRun || sd->errFraming || sd->errBreak) {
while (1) ; <- block to check it in the debugger
}
if (!updateInput(nextByte)) {
At speed of 115200 it works fine. However, at speed of 1Mb/s it starts dropping bytes and the errOverRun counter goes up - BOI interrupt is triggered. I have tried all versions of read - sdRead, chnRead, sdReadTimeout, chnReadTimeout - it always drops data at higher speeds. Can you please advice how to solve the problem?
Sorry if my second question is stupid. Why do we have to disable the interrupts in iqReadTimeout(...) before putting the caller thread to sleep with osalThreadEnqueueTimeoutS(...). Don't we miss the UART interrupt that way?