Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 4 of 4

Thread: Oddball Serial Receive Problem

  1. #1
    Junior Member
    Join Date
    Apr 2017
    Location
    Holt, FL, USA
    Posts
    5

    Oddball Serial Receive Problem

    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!

  2. #2
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,720
    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...

  3. #3
    Junior Member
    Join Date
    Apr 2017
    Location
    Holt, FL, USA
    Posts
    5
    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."

  4. #4
    Junior Member
    Join Date
    Apr 2017
    Location
    Holt, FL, USA
    Posts
    5
    Quote Originally Posted by KurtE View Post
    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!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •