Garbage serial data not making sense

[benoitstjean]

Ok, I have a problem here I can't find what's going-on and it doesn't make any sense at all. I'm using a PIC24HJ128GP306 mounted on the CCS REAL-ICE board. The compiler is 4.132.

> UART1 is going to a GSM module at 115.2kbps and that stream is called SIM908_SERIAL.
> UART2 is going to a PC running CCS's serial monitor on COM1 at 115.2kbps and that stream is called MONITOR_SERIAL.

#INT_RDA is the interrupt for UART1 (SIM908 GSM module). What I do in here basically is that I parse the characters as they are received serially, store them in an array and when I hit the "carriage return" character and I have more than 0 characters, I display the message... and this is where I don't know what's going on.

In plain english:

1) I get the character from the module and store it in the cChar variable.

2) Then, I check if it's a valid ASCII character anywhere between SPACE (0x20) and TILDE (~ / 0x7E) or if it's CARRIAGE RETURN (0x0D) and that my character counter has more than 0 characters

3) If it's between SPACE and TILDE, then I store it in a character array and increment the character counter. For troubleshooting purposes, I added the <fputc( sReceivedData[ulSIM908SerialCharCounter], MONITOR_SERIAL );> to display the received character on my MONITOR CONSOLE.

-> Up to this point, as I receive the serial characters from the SIM908_SERIAL stream, I immediately print them on my MONITOR_SERIAL stream to see the characters on my screen. That works fine. I see all my GSM messages "RDY, +PCASP: 1, GPS Ready etc"....

Then:

4) If the character is CARRIAGE RETURN, that is supposed to mean that it's then 'end' of a GSM message such as "RDY" or "+PACSP: 1" etc. If it's a carriage return, the ulSIM908SerialCharCounter is most likely greater than 0 therefore I simply display the contents of the character array. At this point, the displayed data is pure garbage. But while displaying the individual characters as they are received, then I don't have any problems.

[temtronic]

off the top of my head...

ISRs MUST be short and fast !

Capture the data into a buffer and exit, do the parsing and any resending of data(to PC..) in the MAIN section of your program.

Also, do you have 'errors' added to the use rs232(....) options?


hth
jay

[benoitstjean]

Thanks. I may have found the problem.

This code was working on a PIC18F4620. Going from an 18F4620 with CCS version 4.056 to PIC24 with CCS 4.132, I found new bugs that weren't there before just like the one causing the issue.

I got it to work not long after posting the message. The only difference I did from PIC18 to PIC24 is that instead at the begining of my main(), I added the following lines:

memset( sReceivedData, NULL, sizeof( sReceivedData ));
ulSIM908SerialCharCounter = 0;

After doing this, the errors went away. But I don't understand because in my header file, where I create the character array and the character counter, I declared them like this:

char sReceivedData[DATA_STRING_SIZE] = "";
unsigned long ulSIM908SerialCharCounter = 0;

This has always worked for me but I think that in the newer compiler, it doesn't seem to take for granted that I initialized the variables when creating them therefore I MUST initialize them in my main() before my while(1).

off-topic but related:

The reason I believe this is a "new" bug is that I also have an application that has been functional for over a year on a PIC18F4620 using compiler 4.056. Last week, I had to add a very simple line of code and when I recompiled it under 4.132, the circuit didn't work anymore.

I was able to narrow it down to a line where I do a string compare between two character strings.

I noticed that the 'strcmp' would never return 0 although both strings were identical because I forced them to be the same thing. Then I noticed that when I declared both strings, once of them was a character array of 10 bytes and the other 11 bytes but BOTH had the same 6 characters. As soon as I changed the "10" to an "11", it worked.

[PCM programmer]

[benoitstjean]

Ok, well, that's weird and that's different from previous versions as that code worked perfectly on 4.056.

I've always created variables and initialized them at the same time such as:

char sReceivedData[DATA_STRING_SIZE] = "";

since passing a "null" string ( "" ) would seem to always initialize the array with all NULLS. To be honest, I've never ever encountered any issues under 4.056 and prior. So I guess CCS must have added code in later releases such as the one I'm using...

So basically, what you're telling me is that when I create my variable such as above, then in my main I should always use 'memset' to initialize then entire string to NULL:

memset( sReceivedData, NULL, sizeof( sReceivedData )); ??

[PCM programmer]

I mean to add the line shown in bold below:

[benoitstjean]

Thanks. But it still doesn't explain why it was working in v4.056 and now it's not... other than if CCS modified their code.... and it doesn't make any sense since when declaring the variable < char sReceivedData[ulSIM908SerialCharCounter] = "" >, automatically the array should be filled with nulls....

So then what would be the difference between initializing it with nulls or initializing it with "123456"? If it's initialized, it's initialized, right?

[RF_Developer]

[Ttelmah]

It is important to understand, that initialisation of variables, is something that _you_ need to do properly. You can make the compiler initilise a variableto 0, by declaring it as static. Relying on 'previous behaviour', is a sign of bad programming, since unless a behaviour is explicitly defined (as it is for static variables), it is basically down to luck....

Best Wishes

[benoitstjean]

Yes, that's what I'm starting to realize now (at least with the new version).

Thanks all for your help.