element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • About Us
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Arduino
  • Products
  • More
Arduino
Arduino Forum Serial not receiving all available bytes or state machine hangs
  • Blog
  • Forum
  • Documents
  • Quiz
  • Events
  • Polls
  • Files
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join Arduino to participate - click to join for free!
Actions
  • Share
  • More
  • Cancel
Forum Thread Details
  • State Not Answered
  • Replies 11 replies
  • Subscribers 392 subscribers
  • Views 2103 views
  • Users 0 members are here
  • serial
  • msp430
  • serial.read
Related

Serial not receiving all available bytes or state machine hangs

kas.lewis
kas.lewis over 9 years ago

Hello All,

 

I am attempting to use Energia (I know it's not Arduino but they are pretty much the same) to read data from a serial device that has some interesting quirks. The first issue I'm having is when using the debug code (debug = 1) the program only captures a portion of the serial data from the external device.

 

#define ACK 0x06
#define NACK 0x15
#define CSFAIL 0x51
#define debug 1
#define debugState 1
#define debugStateThree 0


byte requestData[] = {0xA5, 0x08, 0x41, 0x00, 0x3E, 0x4E, 0x20, 0x9A};
int timeSlot = 200;
unsigned long time0 = 0;
unsigned long time1 = 0;
int receiveCounter = 0;
int bytesToReceive = -1;


char reveivedData[50]; //Input array 
boolean stringComplete = false; // whether the string is complete
int outputCounter = 0;
int i = 0;
int state = 0;
char inChar;


int availableBytes = 0;


void setup() {
  // initialize both serial ports:
  Serial.begin(115200);
  Serial1.begin(115200);
  // reserve 200 bytes for the inputString:
  // inputString.reserve(200);
  
  // prints title with ending line break 
  Serial.println("Read Data from MCP39F511"); 
   
}


void loop() {
  //send read data command to MCP39F511
  time1 = millis();
  switch(state){
  case 0:
  if((time1 - time0) >= 1000){
  for(i = 0; i < sizeof(requestData); i++){
  Serial1.write(requestData[i]);
  delayMicroseconds(timeSlot);
  }
  time0 = millis();
  #if debugState
  Serial.println("0 Send Command");
  #endif
  state++;
  }
  break;

  case 1:
  availableBytes = Serial1.available();
  if(availableBytes > 0){
  inChar = (char)Serial1.read();
  if(inChar == ACK){
  reveivedData[receiveCounter] = inChar;
  receiveCounter++;
  state++;
  #if debug
  Serial.print("1 Receive first byte");
  Serial.print(" - inChar ");
  Serial.print(inChar, HEX);
  Serial.print(" - receiveCounter ");
  Serial.print(receiveCounter, HEX);
  Serial.print(" - state ");
  Serial.print(state, DEC);
  Serial.print(" - availableBytes ");
  Serial.println(availableBytes, DEC);
  #endif
  }
  else if(inChar == NACK){
  //Output error message
  Serial.println("Command received with success command not understood or another error in command bytes");
  }
  else if(inChar == CSFAIL){
  //Output error message
  Serial.println("Frame received with success, however, checksum did not match bytes in frame");
  }
  }
  #if debugState
  Serial.println("State #1");
  #endif
  break;

  case 2:
  availableBytes = Serial1.available();
  if(availableBytes > 0){
  inChar = (char)Serial1.read();
  reveivedData[receiveCounter] = inChar;
  bytesToReceive = inChar;
  receiveCounter++;
  state++;
  #if debug
  Serial.print("2 Receive number of bytes to receive");
  Serial.print(" - inChar ");
  Serial.print(inChar, HEX);
  Serial.print(" - receiveCounter ");
  Serial.print(receiveCounter, HEX);
  Serial.print(" - bytesToReceive ");
  Serial.print(bytesToReceive, DEC);
  Serial.print(" - state ");
  Serial.print(state, DEC);
  Serial.print(" - availableBytes ");
  Serial.println(availableBytes, DEC);
  #endif
  }
  #if debugState
  Serial.println("State #2");
  #endif
  break;

  case 3:
  availableBytes = Serial1.available();
  if(availableBytes > 0){
  inChar = (char)Serial1.read();
  reveivedData[receiveCounter] = inChar;
  receiveCounter++;
  if(receiveCounter == bytesToReceive){
  state++;
  #if debugState
  Serial.println("State #3 -> #4");
  #endif
  }
  #if debug
  Serial.print("3 Receive remaining bytes");
  Serial.print(" - inChar ");
  Serial.print(inChar, HEX);
  Serial.print(" - receiveCounter ");
  Serial.print(receiveCounter, HEX);
  Serial.print(" - bytesToReceive ");
  Serial.print(bytesToReceive, DEC);
  Serial.print(" - state ");
  Serial.print(state, DEC);
  Serial.print(" - availableBytes ");
  Serial.println(availableBytes, DEC);
  #endif
  }
  #if debugStateThree
  Serial.println("State #3");
  #endif
  break;

  case 4:
  for(outputCounter = 0; outputCounter < receiveCounter; outputCounter++){
  Serial.print(reveivedData[outputCounter], HEX);
  Serial.print(" - outputCounter ");
  Serial.print(outputCounter, DEC);
  Serial.print(" - receiveCounter ");
  Serial.println(receiveCounter, HEX);
  }
  state = 0;
  #if debugState
  Serial.println("State #4");
  #endif
  break;


  // default :
  // break;
  }

}

 

The device returns 35 bytes but the MSP430 device only sees 16 of them.

image

 

When I turn off debug (debug = 0) but still output the states (except for state 3) the output looks a lot more acceptable but only runs once. It starts to receive the second set of data but stops at state 3.

 

image

 

Once debugStateThree is enabled things really stop working. If left this ends up being an infinite loop.

 

image

 

The data format from the MCP39F511 is a bit odd in that the baud rate is set to 115200 yet the data cannot be sent continuously at that clock speed without breaks, notice the time delay in the send portion of the code, delayMicroseconds(timeSlot); without this the MCP39F511 returns a NACK. Also the returned data is returned in blocks of two bytes.

image

Data sent to the MCP39F511

image

 

Data received from the MCP39F511

image

 

I did attempt to use SerialEvent but that did not seem to run correctly or how I was hoping it would. If anyone can give me some pointers as to what I may be doing wrong and why the code appears to run erratically I would very much appreciate the help.

 

Thankfully

Kas

  • Sign in to reply
  • Cancel

Top Replies

  • kas.lewis
    kas.lewis over 9 years ago in reply to kas.lewis +2
    The answer I found in my last post. Thanks to Robert Peter Oakes suggestion of trying less than 16 bytes I was able to see that the receiveCounter value a bit clearer. If you look in the last picture in…
Parents
  • Robert Peter Oakes
    0 Robert Peter Oakes over 9 years ago

    I'm with shabazon this one.

     

    I was just helping a friend with a very similar issue but in this case it was the I2C library and it had a buffer limit of only 32 bytes (In two places)

     

    In order to preserve resources, it is often the case that the libraries will have fixed size buffers to allow as much ram as possible for your application

     

    If your not using much of the ram in your code, you can change the library buffer sizes and see if this fixes the problem or as shabaz stated, break up the message into 16byte chunks.

     

    either way this is most certainly a buffer issue,

     

    Regarding the break up of the data into small packets. this will be due to the hardware uart being able to take one or two bytes (Depends on the hardware used) but then the handler to give it the next one or two characters is several software levels up from it so it takes time to process and get back down to the hardware. This is especially try of environments like Arduino etc that are based on Wiring where there is a lot of abstraction between your application and the real hardware,

     

    to improve this you would have to code at a much lower level and talk direct to the hardware uarts with your code.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • kas.lewis
    0 kas.lewis over 9 years ago in reply to Robert Peter Oakes

    I just increased the buffer size in "energia-1.6.10E18\hardware\energia\msp430\cores\msp430\HardwareSerial.cpp" to 32, 128 and 256. In all cases teh results were the same.

     

    Kas

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
Reply
  • kas.lewis
    0 kas.lewis over 9 years ago in reply to Robert Peter Oakes

    I just increased the buffer size in "energia-1.6.10E18\hardware\energia\msp430\cores\msp430\HardwareSerial.cpp" to 32, 128 and 256. In all cases teh results were the same.

     

    Kas

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
Children
  • Robert Peter Oakes
    0 Robert Peter Oakes over 9 years ago in reply to kas.lewis

    it may also be defined in another place. I found that out the hard way for the I2C library

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • kas.lewis
    0 kas.lewis over 9 years ago in reply to Robert Peter Oakes

    Hello Robert Peter Oakes

     

    Looking at the second line of the compile output "Global variables use..." I can see that when the buffer is set to 16 bytes only about 4% is used but when I change it to 256 it jumps to 58% and if I try 512 I run out of ram. I would conclude the buffer size is increasing but testing this on both a MSP430FR5969 an MSP430F5529 have given me teh same results.

     

    The reality is I'm only using Energia because M2X has a library that yo can use without needing an RTOS or other OS. If I could use their C library without needing a RTOS I would happily do so. I may look at other IoT cloud services again to see if I can find another easy to use one that will allow for native C to be used.

     

    Kas

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • Robert Peter Oakes
    0 Robert Peter Oakes over 9 years ago in reply to kas.lewis

    my only other thought right now is that the serial coms is being interrupted some how. possibly the serial is locking code execution while your performing the debug statements or other operations on one serial port while trying to use the other. (This is just speculation on the possibility that the coms are running under interrupts and priority is interfering or that the code is locked while some of the operations are occurring on one port under an interrupt preventing the other from creating the required events.

     

    I don't have time right now to look deeper into it so good luck with the trouble shooting and please let us know if you resolve it

     

    Peter

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • kas.lewis
    0 kas.lewis over 9 years ago in reply to Robert Peter Oakes

    I have now reduced the amount of data requested to see if there is anyway the buffer is the issue. The code was changed to request TWO bytes of data. For this there are a total of FIVE bytes returned (header, number of bytes, data[2] and checksum). This would allow for a lot of space in the buffer and should prevent any issues.

     

    image

    0xA5 - 0x40 is the data sent to the MCP39F511

    0x06 - 0x0B is the data returned to the MSP430

     

    image

    Data packet sequence that is sent and returned to and from the MCP39F511

     

    image

    As can be seen from the above image this did not resolve the issue (debugState = 1). The program still hangs after receiving the first data received from the MCP39F511.

     

    image

    All debugs have been disabled.

     

    image

    With debug = 1 the program still stops after the first iteration, it starts teh second but teh program does not continue.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • kas.lewis
    0 kas.lewis over 9 years ago in reply to kas.lewis

    The answer I found in my last post. Thanks to Robert Peter Oakes suggestion of trying less than 16 bytes I was able to see that the receiveCounter value a bit clearer. If you look in the last picture in teh above post the counter counts up to 0xA but there are never more than 5 bytes in the packet. This led me to realize the counter was not being reset and as such the once the first set of data was received the condition to ignore receiving more data was always true.

     

    As of this writing the program has been pulling data over serial for almost 3 hours even though its only been 5 bytes and not the 35 or so I will hopefully get working later.

     

    Kas

    • Cancel
    • Vote Up +2 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • Robert Peter Oakes
    0 Robert Peter Oakes over 9 years ago in reply to kas.lewis

    Looks like your almost there, this looks to be an interesting power monitoring project

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2025 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube