LPC1343 Software UART Problem (AN10955)

[lpcware]

Content originally posted in LPCWare by staffan on Sat Dec 11 04:20:50 MST 2010
Hello,

I am using the LPC1343 on an LPCXpresso dev board in an application where i receive data from a GPS-receiver and transmit it via a bluetooth module. The BT is connected to the hardware UART and the GPS is using software uart according to app note AN10955.

The GPS sends $GPGLL strings (around 50 chars long) once every second (4800 baud). The swUART receiver interrupt puts received characters in a buffer and when '\n' is received (indicates end of string) '\0' is appended, the string is copied to another array using strcpy() and a flag is set to indicate that new data is availiable.

The main loop just checks the flag and sends the queued data using UARTSend() from in the UART example.

The problem is that the swUART stops receiving characters after a while.The time it takes until failure is random. Sometimes it works for several minutes, sometimes it fails after a few seconds and sometimes it magically starts working again.

Could it be because something disturbs the timer interrupt used by the swUART?

Or could it be because i spend too much time inside the interrupt when a complete string is received? This feels unlikely because it works so well for a long time before it fails.

If i stop the program when the problem have ocurred i get wierd values for some of the swUART's global variables (cnt_bits == -104 or -94 or 65 etc..) Could it be because the swUART gets out of sync somehow?

This is the only code in the swUART example that i have modified apart from removing the code for debug pins. It is where i end up when a character is received.

void swu_rx_callback(void)
{
//append flag bit to character
rxData = 0x100 + swu_rx_chr();

buffChar=(unsigned char) rxData & 0xFF;
if (buffChar == '\n')
{
GPSBuffer[GPS_Index++]='\n';
GPSBuffer[GPS_Index++]='\0';
strcpy(GPSqueued,GPSBuffer);
GPSFlag=1;
GPS_Index=0;
//swu_tx_str( (unsigned char*) GPSqueued);
}
else
{
GPSBuffer[GPS_Index++] = buffChar;
}
rxData=0;

return;
}

Any help woould be appreciated

Regards,
Staffan

Original Attachment has been moved to: 1100903_LPCXpresso.zip

[lpcware]

Content originally posted in LPCWare by liporew on Fri Apr 13 03:44:38 MST 2012
Every other bytes, ascii codes, are send properly.

For values send from PC
0x81 =  0b 1000 0001
SWU get 0b 1000 0010 (0x82)

0xAA =  0b 1010 1010
SWU get 0b 1101 0100 (0xD4)

If I try to send from software UART to PC this values
everything looks OK, it sends 0xAA and 0x81 properly.

I will try to find why is that but any help will be appreciated.

"update"
comment/remove this line (361) to fix problem mentioned above
swu_rbr = swu_rbr << (cnt-1); //... make space for the rest...
in lpc_swu.c
in void swu_isr_rx(LPC_TMR_TypeDef* const RX_ISR_TIMER)

[lpcware]

Content originally posted in LPCWare by domen on Fri Dec 17 09:09:09 MST 2010
As mentioned, used the circular buffer, do the parsing out of interrupts

[lpcware]

Content originally posted in LPCWare by gbm on Tue Dec 14 02:16:44 MST 2010
I a not sure about the exact source of your problem, but depending on how the software UART is implemented it may need to respond to an interrupt in 1/2 or 1/4 of bit time slice. There might be a problem with handling of the last character's stop bit when using strcpy.
If you don't expect the next sentence while processing the current one, you may use single buffer, disabling data reception of (better) buffer filling for the time when you process your data.

[lpcware]

Content originally posted in LPCWare by staffan on Mon Dec 13 14:24:43 MST 2010
Thanks for your response gbm,

The reason i'm copying the received string to a new location is so I can start receiving the next line while parsing the first one... I realize this isn't the optimal way of doing it but I think it should work, especially because I only get one string every second so there's heaps of time in between.

I still don't understand why it doesn't work the way i've written it, mainly for tree reasons:

1. When the last character of a line is received there is almost a second until next UART activity. This should give me plenty of time to copy my string. Or am i missing something in how the soft UART works? Am I disturbing it in any way? What are its "weak spots" that i need to be aware of?

2. The same problem occurs independently of wether the GPS has a position fix (= longer strings) or not (= shorter strings).

3. It works well for a period of time before it hangs. If the copy took too long it should either be working or not, possibly depending on the string length, am i right?

I will look into making a FIFO buffer instead, I agree that is a smarter and faster way of doing things.

[lpcware]

Content originally posted in LPCWare by gbm on Sun Dec 12 04:56:47 MST 2010
Use of strcpy may be the problem - it might take significant time. Why don't you use single circular buffer (fifo) for softUART reception, marking the presence of whole line at reception of '\n' with the same flag you already have? You don't get anything from copying the characters from one buffer to another.