peter staelens

Important changes to forums and questions

All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.

9 years, 5 months ago.

serial problem on uart port

/media/uploads/Peterbarco/schematic.jpg /media/uploads/Peterbarco/fmt_logger_serail_details.pdf /media/uploads/Peterbarco/fmt_logger.docx All, i have an issue with a serial port. In attachement the schematic of my system. I have a serial port coming from the PC to the MBED and 1 leaving to a unit who has to respond. The PC is sending data and depending on the result (KEY CURRENT) the MBED responds direct to the PC again. If not the MBED sends its received data to an unit. That unit will then respond back to the PC. Every command ends with a OD (ENTER command). As long as the received strings are well seperated from eitch other then there is no problem. If I receive a command like this: key serial0Dkey q0D then the system hangs. Because the string received is not a KEY CURRENT command the MBED should send this string back out but it only transmits 3 characters and thats it. It even hangs. Some experienced software engineers looked over the soft but could not found any problem. it looks as if this is something typcial for the MBED.

Can someone help me.

Staelens Peter Belgium

Can you also post the relevant code (between <<code>> and <</code>>)?

Edit: nvm, see that it is in the docx. In general copy pasting between code tags is easier for everyone though :)

posted by Erik - 01 Dec 2014

1 Answer

Wim Huiskamp
9 years, 5 months ago.

Most likely cause is timing issue. Your RX interrupt handler will continue to read from serial port while your main is interpreting the message it received just before. So while main processes "key serial 0D" and recognises that as a message for a unit, the RX receives the complete next message "key q 0D" and cant store it in rx_buffercopy since (ready!=0) So the message might get lost. Note that strncmp() is a slow operation that takes a bit of time. So does device.printf(). Some additional checks or temporary disable of the interrupt could fix this.

You may also need a check in the RX interrupt that you dont store the ''\0'' in rx_buffer[buffer_size].

Accepted Answer

This should be easy to test for, change an LED if the test for (ready == 0) on line 200 fails. Or as a quick hack to test the theory slow the baud rate down to 9600 so it has more time to process the message (not a fix but if that works you know it's almost certainly timing related).

posted by Andy A 01 Dec 2014

Wim, Maybe we should switch to Dutch. If I use the RX from UART2 and the transmit on UART1 then all works fine. It has to do something with the TX together with the receive on the same port.

posted by peter staelens 02 Dec 2014