Oddball Serial Receive Problem

Status
Not open for further replies.

nemiro

Member
I am using a Teensy 3.6, and am connecting to a PC via USB. I have a program that runs on the PC that sends various commands to the Teensy to get it to do things. In this case, I have a command that sends a hex 0x01, and then a string of hex commands to get it to read a file list of an SD card. The code works properly. However, if I change unrelated code - nothing to do with the serial port, SD card, or any of that, I will occasionally break the serial port RECEIVE side. ie, what the Teensy sees from the PC changes (not what Teensy transmits back to the PC. I am no where close to using up the memory, and have tried to comment out large sections of code to attempt to affect this. Nothing related to the serial port or its functions affects this, but I can show what happens. The code reads bytes coming in from the serial port, processes them, and then outputs them back to the serial port. Under most circumstances all is normal, and it works fine. Here's what is looks like when all is well (all from serial captures):

(first line here is the command transmitted from the PC)
01 41 00 00 ff ff ff ff 17 d9 81 4f 95 04 .A.......ف.O.. <-Notice the first byte is 0x01.

Teensy processes the data coming in, and then spits the message back out, with some metrics:
4c 53 42 3a 20 30 0d 0a 4d 53 42 3a 20 30 0d 0a LSB: 0..MSB: 0..
56 61 6c 75 65 3a 20 30 0d 0a 50 61 63 6b 65 74 Value: 0..Packet
20 52 65 63 65 69 76 65 64 0d 0a 6d 65 73 73 61 Received..messa
67 65 42 79 74 65 73 4c 65 6e 67 74 68 3a 20 31 geBytesLength: 1
34 0d 0a 30 78 31 2c 20 30 78 34 31 2c 20 30 78 4..0x1, 0x41, 0x <-Notice the first byte it outputs is 0x1 (0x01), which is what I expect
30 2c 20 30 78 30 2c 20 30 78 46 46 2c 20 30 78 0, 0x0, 0xFF, 0x
46 46 2c 20 30 78 46 46 2c 20 30 78 46 46 2c 20 FF, 0xFF, 0xFF,
30 78 31 37 2c 20 30 78 44 39 2c 20 30 78 38 31 0x17, 0xD9, 0x81
2c 20 30 78 34 46 2c 20 30 78 39 35 2c 20 30 78 , 0x4F, 0x95, 0x
34 0d 0a 4c 53 42 3a 20 30 0d 0a 4d 53 42 3a 20 4..LSB: 0..MSB:
30 0d 0a 56 61 6c 75 65 3a 20 30 0d 0a 49 73 20 0..Value: 0..Is
4d 65 73 73 61 67 65 20 43 52 43 20 56 61 6c 69 Message CRC Vali
64 3a 20 31 0d 0a 5b 49 4e 46 4f 5d 20 47 45 54 d: 1.. <-This 1 indicates that the parser got what it wanted, and the message is valid. Good!
<snip>

Now, change up unrelated code, and I get the following:

01 41 00 00 ff ff ff ff 17 d9 81 4f 95 04 .A.......ف.O.. <- notice the first byte is 0x01

The response from Teensy:
4c 53 42 3a 20 30 0d 0a 4d 53 42 3a 20 30 0d 0a LSB: 0..MSB: 0..
56 61 6c 75 65 3a 20 30 0d 0a 50 61 63 6b 65 74 Value: 0..Packet
20 52 65 63 65 69 76 65 64 0d 0a 6d 65 73 73 61 Received..messa
67 65 42 79 74 65 73 4c 65 6e 67 74 68 3a 20 31 geBytesLength: 1
34 0d 0a 30 78 30 2c 20 30 78 34 31 2c 20 30 78 4..0x0, 0x41, 0x <-Now the received first byte is 0x00!
30 2c 20 30 78 30 2c 20 30 78 46 46 2c 20 30 78 0, 0x0, 0xFF, 0x
46 46 2c 20 30 78 46 46 2c 20 30 78 46 46 2c 20 FF, 0xFF, 0xFF,
30 78 31 37 2c 20 30 78 44 39 2c 20 30 78 38 31 0x17, 0xD9, 0x81
2c 20 30 78 34 46 2c 20 30 78 39 35 2c 20 30 78 , 0x4F, 0x95, 0x
34 0d 0a 4c 53 42 3a 20 30 0d 0a 4d 53 42 3a 20 4..LSB: 0..MSB:
30 0d 0a 56 61 6c 75 65 3a 20 30 0d 0a 49 73 20 0..Value: 0..Is
4d 65 73 73 61 67 65 20 43 52 43 20 56 61 6c 69 Message CRC Vali
64 3a 20 30 0d 0a 63 6f 41 48 7e 5e 55 42 61 69 d: 0.. <- doesn't pass the parser, so message is invalid


I am not allowed to post the code. It is too big/proprietary, blah blah blah. I'm just looking for general suggestions on how to approach this. I have been using Teensy's for years, now, and have never seen this happen.

The big thing is this appears like some sort of memory leak, but I really can't find it. According to the compiler, we are only using about 17% of the capacity. All we're doing in this section of code is reading in what Teensy sees on its serial port, and then spitting it back out with parser messages. It is as if Teensy does not see that first bit. Is there a way to flush out the receive buffer, or some other way to limit the serial port, so that it won't miss that bit? Any constructive suggestions are more than welcome. Thanks!
 
Again without seeing code or the like, it sounds like a memory corruption issue.

Often times this can be caused by having an array or the like before what it is you are outputting that is over run.

Examples include things like:
Using an array thinking of it as one biased instead of 0...
Code:
uint8_t a[5];
for (uint8_t i=1; i<= 5; i++) a[i] = 0;

Or something like:
Code:
uint8_t mystr[4];
strcpy (mystr, "ABCD");
Where you forgot to leave room for trailing null character,

But there are lots of other ways as well...
 
Thank you, Kurt! That at least gives me a direction to head into. I wish I could out the code up, but management says, "No."
 
Again without seeing code or the like, it sounds like a memory corruption issue.

Often times this can be caused by having an array or the like before what it is you are outputting that is over run.

Examples include things like:
Using an array thinking of it as one biased instead of 0...
Code:
uint8_t a[5];
for (uint8_t i=1; i<= 5; i++) a[i] = 0;

Or something like:
Code:
uint8_t mystr[4];
strcpy (mystr, "ABCD");
Where you forgot to leave room for trailing null character,

But there are lots of other ways as well...



Kurt (and to anyone else who might hit this issue),
You were spot on! Had an array that was initialized, but did not take into account thew NULL, so it was causing the issue. Thank you so much for the lead, it made this process much less frustrating!
 
Status
Not open for further replies.
Back
Top