CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

Homemade string compare randomly fails [Solved]
Goto page Previous  1, 2, 3  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
temtronic



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Wed May 25, 2022 7:49 pm     Reply with quote

So the data is coming from a 'Windows PC' via RS232.

Is this a 'bare bones' PC with NO internet connection and ONLY the 'terminal program' that communicates with the PIC ?
If not there are several possible 'gremlins'.... such as 'auto-update' programs becoming active, Internet communications, some program or app running in the background.... Any recent (15 years or newer) PC probably doesn't have RS-232 ports, so do you have a USB<> RS232 module, or a USB<>TTL module as the interface ? If USB<>???, there's a LOT of 'layers' of code,and any one of them could be the 'gremlin'.

It'd be best to program another PIC to be the 'host', and 'emulate' the PC side of the communications. This ELIMINATES the PC as being the problem.

BTW you do have a good GROUND between the PC and the PIC ???
If 'RS-232' are you saying read RS-232 where signals are +-12 volts or the 'cheat' of 0,+5 for signals ?

Finding a 'random' failure is a HUGE task, more a process of elimination. It took me over month to find out that 'crosstalk' on some Bell telephone lines was the gremlin in one system......
julienm



Joined: 28 Jul 2020
Posts: 31

View user's profile Send private message

PostPosted: Thu May 26, 2022 3:33 am     Reply with quote

@PCM Programmer: I cannot carefully check that before next Monday

On the other hand, I confirm that with the additional printf, the bug won't appear within 15k cycles when it is usually guaranteed to fail within the first 2k cycles.

@temtronic: How could the PC be the problem when the content of the buffer received over rs232 is always correct when the bug appears?
usb/serial conversion is done by an ftdi next to do the PIC

What do you mean with "a good GROUND between the PC and the PIC"?
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Thu May 26, 2022 3:54 am     Reply with quote

julienm wrote:

I confirm that with the additional printf, the bug won't appear within 15k
cycles when it is usually guaranteed to fail within the first 2k cycles.

Check the .SYM file. Look for a place where you are writing past the
end of an array.

Other threads on this topic:
http://www.ccsinfo.com/forum/viewtopic.php?t=48674
http://www.ccsinfo.com/forum/viewtopic.php?t=46536
temtronic



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Thu May 26, 2022 5:25 am     Reply with quote

re:
Quote:

How could the PC be the problem when the content of the buffer received
over rs232 is always correct when the bug appears?

Do you have you some sort of external monitor to 'see' the actual data going
from the PC to the PIC ? If so, and it confirm the data IS correct, then not a
PC or connection problem.
julienm



Joined: 28 Jul 2020
Posts: 31

View user's profile Send private message

PostPosted: Wed Jun 01, 2022 1:41 pm     Reply with quote

I've ran a new test that printed only 2 characters in order to avoid adding enough delay to prevent the bug to appear:
Code:
BOOLEAN startsWith(char *txt, char *toCompare)
{
    int8 size = strlen(toCompare);
    int8 i = 0;
   
    while( i < size )
    {
        if( txt[i] != toCompare[i] ) return FALSE;
        i++;
    }
    printf("%c%c", txt[0], txt[1]);
    return TRUE;
}

When the bug occurs, there's no printf, which (I suppose) means that the function return before, ie. it should have returned FALSE ...

The string sent by the PC is always correct, using the ICD debugger I can see the buffer and it always contains what was expected.

I've not found arrays that could be written past their end.
temtronic



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Wed Jun 01, 2022 2:25 pm     Reply with quote

OK, have to ask ..where are you sending the printf(...) data from the PIC to ?
julienm



Joined: 28 Jul 2020
Posts: 31

View user's profile Send private message

PostPosted: Wed Jun 01, 2022 3:20 pm     Reply with quote

Over RS232 back to the PC.
Maybe I should have explain that before the bug occurs I have 3000 working cycles, and for each cycle maybe 30 printf that do work properly.
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Wed Jun 01, 2022 5:00 pm     Reply with quote

You seem reluctant to check the hardware for potential problems that
I listed in the post below (and the links):
http://www.ccsinfo.com/forum/viewtopic.php?t=59771&start=14

Here are two links about board layout problems that can cause erratic
operation:
http://www.ccsinfo.com/forum/viewtopic.php?t=52859&start=13
http://www.ccsinfo.com/forum/viewtopic.php?t=41964&start=1

You could run a simple test program as shown below. It puts constant
values into the startsWith() function. You could run it for several hours
and see if it fails. If it does, I'm going to suspect a hardware problem.
Code:
 
#include <18F6722.h>
#device PASS_STRINGS=IN_RAM
#fuses NOWDT
#use delay(internal=8M)
#use rs232(baud=9600, UART1, ERRORS)

#include <string.h>

BOOLEAN startsWith(char *txt, char *toCompare)
{
int8 size = strlen(toCompare);
int8 i = 0;

while(i < size)
  {
   if(txt[i] != toCompare[i]) return FALSE;
      i++;
  }
printf("%c%c", txt[0], txt[1]);
return TRUE;
}


//==============================
void main()
{

int8 cmd_buf[] = "AB";

while(TRUE)
  {
   if(startsWith(cmd_buf, "AB"))
      printf("Found string\n\r");
   else
     {
      printf("Did not find string\n\r");
      break;
     }
  }

printf("Test halted\n\r");

while(TRUE);
}
temtronic



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Wed Jun 01, 2022 5:12 pm     Reply with quote

I'd get even simpler...

Install a loopback wire from the TTL xmit to TTL rcv of the USB adapter.
Cut a small test program on the PC to send the 'data' and another to receive the 'data'. If the received data doesn't match, flag it and continue. Run the test for at least 48 hours nonstop.
If there are ZERO errors in that time period, it almost eliminates the PC as being the source of the problem.
Now code and run PCM P's program...

BTW what language are you using to send/receive the data ?
julienm



Joined: 28 Jul 2020
Posts: 31

View user's profile Send private message

PostPosted: Thu Jun 02, 2022 8:49 am     Reply with quote

@PCM: I'm testing your program right now, no problem so far (but since no RDA interrupts are generated, I don't expect the bug to occur)

I confirm our 5Vdc voltage is stable, the 4 pins are connected to power and ground. the capacitor are there and could not be closer to the pins.

@temtronic: I don't understand your concerns with the PC, the problem has nothing to do with garbage on the rs232 sent by the PC, each time I have an error, I can check with the ICD that all the characters buffers received by the PIC are correct.
Bad characters would not result in "garbage" == "fbon" --> TRUE
temtronic



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Thu Jun 02, 2022 12:04 pm     Reply with quote

re: I can check with the ICD that all the characters buffers received by the PIC are correct.

You're making a HUGE assumption that the PC and ICD program ARE telling you the truth. It is possible that the ICD is only re-reading the same data in a buffer, doesn't ERASE the buffer before more/new data is added ?
Most here understand that EVERY schematic made by Proteus will NOT function/work in the real World. I don't use whatever 'ICD' you're using.
It should only take you 10-15 minutes using, say DELPHI, to cut a program to test that it is NOT the 'PC side' that is causing the problem. You could even use a terminal program like RealTerm to test.
Also you say RS-232 but is it a USB<>TTL or USB<>RS-232 module ? They require different hardware !
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Fri Jun 03, 2022 1:53 am     Reply with quote

What is your CCS compiler version ?

In the thread below, you have vs. 5.080 (released July 21, 2018) and you
have corrupted variables:
http://www.ccsinfo.com/forum/viewtopic.php?p=238441&start=3
Are you still using vs. 5.080 ?

Some bugs in 5.080 fixed in later versions:
5.081 A bug with int1 arrays inside structures on some parts is fixed.
5.081 A bank switching optimization bug affecting all PIC18 parts is fixed.
5.082 An optimization bug when there is a lot of bank switching in a conditional of an IF is fixed.
5.082 Fixed an issue with i2c_transfer() function not using correct stream when using multiple I2C streams.

If you are still using vs. 5.080, you could try putting this line near the
start of your program, just to see if it fixes things:
Code:
#opt 0
PrinceNai



Joined: 31 Oct 2016
Posts: 452
Location: Montenegro

View user's profile Send private message

PostPosted: Fri Jun 03, 2022 5:37 am     Reply with quote

If I missed that question, sorry. Does it always fail on the same string?
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Sun Jun 05, 2022 1:25 am     Reply with quote

He seems to be saying it is 'random'.
One thought is, that CTS to a PC, does not stop data immediately. On
most PC's there is a 16 character serial output buffer and characters
already in this are sent after CTS changes. Result could be the next string
starting to arrive before the firs one is processed. This could easily mean
that the LF gets overwritten in the buffer etc..
julienm



Joined: 28 Jul 2020
Posts: 31

View user's profile Send private message

PostPosted: Sun Jun 05, 2022 2:01 am     Reply with quote

@PCM first thing I did was to update to compiler v5.109, but I have not tested disabling optimisations yet, that was on my todo list
@Prince: although the issue occurrence is random, it is indeed almost always at the same command
@TTelmah: I also believe the problem is caused by the next string being send while the previous one is still process (although this should be handled properly by the firmware) but I have not understood your explanation with CTS, can you just detail a bit?
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page Previous  1, 2, 3  Next
Page 2 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group