4.2 kernel, serial port lost data, need help from experts[Copy link]
The application ClearCommError function prompts a CE_OVERRUN error. If (IntSubPndVal & (pHWHead->bErrINT)) in the driver's SL_GetInterruptType function is true, indicating that an error has occurred. In the ReadLSR function called in the SL_LineIntr function, LineStatus = INREG(pHWHead,rUERSTAT); if (LineStatus & COM2440_LSR_OE) is true, indicating that an OverRun error has occurred. In the baud rate setting function SetBaudRate, the baud rate is set as follows OUTREG(pHWHead,rUBRDIV,( (int)(S2440PCLK/16.0/BaudRate) -1 )); S2440PCLK is 50M, crystal is 16.934M, baud rate is set to 57600 or 115200. When the amount of data sent per second exceeds 3000 bytes, such an error will occur. Uart1 and Uart2 are so frequent. When the touch screen is swiped, the error probability is very high. I thought it was a problem of interrupt priority. Adjust the interrupt priority register PRORITY, or OverRun. The level of the serial port monitoring thread is #define DEFAULT_CE_THREAD_PRIORITY 103. Change it to 97 or OverRun. Can an expert help analyze the problem? It's okay to give some tips. This problem has troubled me for a long time. I will give you extra points for solving the problem! Waiting for reply online!
Thank you all for your enthusiastic help. I am a little busy with the project at hand and I am too busy to finish it. I understand what the masters mean. I will give you some points first and post the modified results after testing them later.
Details
Published on 2008-11-7 09:25
It feels necessary to confirm: 1. In the state of data loss, whether the serial port has crashed and whether the mouse can be moved; 2. In the case of data loss, is it the sent data that is lost, or the received data that is lost; If it is related to the sliding touch screen, then the system's operating efficiency and other interruptions are also involved.
To the 5th floor, there is no freezing phenomenon, and the sending data is not lost. Only when receiving, the data volume per second starts to be lost after a large amount of data is received. I have set the interrupt level of Uart2 higher than the touch screen timer. Now Uart2 is the highest interrupt level, but it still loses data. I have set the serial port monitoring thread level to 97, but it still overruns. To the 6th floor, the serial port buffer of 2440 is 64 bytes, can it be set? The UFCON register is only used to set what situation triggers the interrupt. OUTREG (pHWHead, rUFCON, 0x41); I set it like this. I set the receiving interrupt trigger to 1Byte. I understand that every 1Byte received will trigger the serial port interrupt. Thank you for your help. The problem is still not solved. I will continue to wait tomorrow.
Serial port drivers are all prepared by MS. If you can find the problem, MS will give you a VIP certificate! So many companies have made countless GPS software using serial ports without any problems, but you have a problem. I think MS will be very sorry if it doesn't give you a title!
What is the trigger byte of the FIFO? Don't set it too high. If the receiving thread is not fast enough, data may be lost. It is recommended to look at the part you drive.
It seems like a problem with the FIFO threshold setting of the serial port driver. If you don't know much about the serial port driver, I suggest you look for the official BSP to see the corresponding code. After all, there are many people using 2440.
xqhrs232 If you understand, please help analyze the problem, don't do unnecessary things. The BSP package is given by the manufacturer when the development board is purchased. I don't know if it is written by MS. There is no problem with the kernel running GPS, but the data will be lost when the amount of data transmitted per second is large. Currently, 3000 bytes is a dividing point. Replying to the brothers on the 9th and 10th floors, I set OUTREG(pHWHead,rUFCON,0x41);, which should be triggered once every 1 byte received. There is no loss of data when the bytes transmitted per second are less than 3000, and the data will be lost only when the amount of data is large. I can't determine whether the problem is in the register setting or in the thread processing. If the threads of other drivers run very frequently, will it also affect the processing of serial port data? Now there will be such a problem when the touch screen is swiped frequently. Is it because the timer in the touch screen thread is triggered too frequently? Or is the serial port monitoring thread level too low? I think 97 is not low.
I can't analyze it! You can write a simple serial port AP to test it and see if there is a problem with your serial port driver or something! Generally, this situation will not occur!
The number of bytes that trigger the FIFO interrupt cannot be too small, otherwise it will cause too frequent interrupts. If it is set too large, if the receiving thread is inefficient, data will be lost. It is recommended to set it to 4 bytes or 8 bytes to try, an intermediate value. If you suspect that the problem is with the receiving thread processing, you can comment out the relevant processing code first and only count the number of bytes received. In addition, if the system is processing other things, it should affect the reception of the serial port.
Quote from yangyong9608 on the 7th floor: To the 5th floor, there is no freeze, and the data is not lost when sending. Only when receiving, the data volume per second starts to be lost when it is large. I have set the interrupt level of Uart2 higher than the touch screen timer. Now Uart2 is the highest interrupt level, but it still loses data. I have set the serial port monitoring thread level to 97, but it still overruns. To the 6th floor, the serial port buffer of 2440 is 64 bytes, right? Can it be set? The UFCON register is only used to set the situation that triggers the interrupt. OUTREG (pHWHead, rUFCON, 0x41); I set it like this. I set the receive interrupt trigger to 1Byte,…
I have also encountered your problem. There is no problem with sending small data at a time, but if you send large data at a time, there will be a problem of data leakage in the middle. //OUTREG(pHWHead,rUFCON,0x41); //FIFO enable : tx-4bytes, rx-4bytes OUTREG(pHWHead,rUFCON,0xf1); //FIFO enable : tx-48bytes, rx-32bytes After I reset the receive data buffer, the problem was solved. I don’t know if it can solve your problem. P.S.: However, I did not encounter the problem of data leakage caused by touch.
Quote from sunrain_hjb's reply on the 14th floor: The number of bytes that trigger the FIFO interrupt cannot be too small, otherwise it will cause too frequent interrupts. If it is set too large, if the efficiency of the receiving processing thread is low, data will be lost. It is recommended to try setting it to 4 bytes or 8 bytes, an intermediate value. If you suspect that it is a problem with the receiving thread processing, you can comment out the relevant processing code first and only count the number of bytes received. In addition, if the system is processing other things, it should affect the reception of the serial port.
Yes, step by step, you can block all drivers to see if there will be any loss; then the interrupt value should not be too small or too large. 1, I think it is too small...
Thank you all for your enthusiastic help. I am a little busy with the project at hand and I am too busy to finish it. I understand what the masters mean. I will give you some points first and post the modified results after testing them later.
提升卡
变色卡
千斤顶
京公网安备 11010802033920号
