| View previous topic :: View next topic |
| Author |
Message |
temtronic
Joined: 01 Jul 2010
Posts: 9215
Location: Greensville,Ontario
|
|
 Posted: Wed May 25, 2022 7:49 pm |
 |
|
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
|
|
| Posted: Thu May 26, 2022 3:33 am |
|
|
@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
|
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9215
Location: Greensville,Ontario
|
|
| Posted: Thu May 26, 2022 5:25 am |
|
|
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
|
|
| Posted: Wed Jun 01, 2022 1:41 pm |
|
|
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: 9215
Location: Greensville,Ontario
|
|
| Posted: Wed Jun 01, 2022 2:25 pm |
|
|
| OK, have to ask ..where are you sending the printf(...) data from the PIC to ? |
|
|
julienm
Joined: 28 Jul 2020
Posts: 31
|
|
| Posted: Wed Jun 01, 2022 3:20 pm |
|
|
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
|
|
| Posted: Wed Jun 01, 2022 5:00 pm |
|
|
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: 9215
Location: Greensville,Ontario
|
|
| Posted: Wed Jun 01, 2022 5:12 pm |
|
|
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
|
|
| Posted: Thu Jun 02, 2022 8:49 am |
|
|
@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: 9215
Location: Greensville,Ontario
|
|
| Posted: Thu Jun 02, 2022 12:04 pm |
|
|
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
|
|
| Posted: Fri Jun 03, 2022 1:53 am |
|
|
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:
|
|
|
PrinceNai
Joined: 31 Oct 2016
Posts: 471
Location: Montenegro
|
|
| Posted: Fri Jun 03, 2022 5:37 am |
|
|
| If I missed that question, sorry. Does it always fail on the same string? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19477
|
|
| Posted: Sun Jun 05, 2022 1:25 am |
|
|
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
|
|
| Posted: Sun Jun 05, 2022 2:01 am |
|
|
@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? |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
