Jump to content
gdmt

MSP430F5529LP + 430BOOST-CC110L - Execution randomly hangs

Recommended Posts

hi everyone, this is my first post in this forum, hope this can be a starting point for a proficuous collaboration.

i developed a quick cable replacement solution with 2 MSP430F5529 LaunchPads and 2 CC110L AIR Module BoosterPacks.

 

here's a quick sketch of the desired solution.

Host PC <-- [uSB/CDC] --> LaunchPad+AIR ---|  |--- LaunchPad+AIR <-- [uART] --> Slave Microcontroller

 

the idea behind the two firmwares is that one LaunchPad acts as a master and the other LaunchPad acts a slave.

  • a Host PC sends a string to the master LaunchPad through USB/CDC.
  • master LaunchPad: if the string is "info-master" locally return the string "master" else transmit the string.
  • slave LaunchPad: if the string is "info-slave" than transmit the string "slave" else send the string through serial, read and transmit the response.

the problem with this code is that, randomly, after many days the master OR the slave stop working ... after a powercycle, everything works again.

 

i suspect the while(Radio.busy()); plays a role in this problem.

 

here's the master's code:

#include <SPI.h>
#include <AIR430BoostETSI.h>
#include <USBSerial.h>

USBSerial mySerial(1);
uint8_t i = 0;

void setup()
{
  Radio.begin(0x01, CHANNEL_1, POWER_MAX);

  mySerial.begin();

  pinMode(RED_LED, OUTPUT);
  pinMode(GREEN_LED, OUTPUT);
  digitalWrite(RED_LED, HIGH);
  digitalWrite(GREEN_LED, HIGH);
}

char buffer[50];
int j;

void loop()
{
  for(j = 0; j < 50; j++) 
    buffer[j] = 0x00;

  mySerial.readBytesUntil(' ', buffer, 50);
  
  if(strlen(buffer) > 0)
  {
    if(strcmp(buffer, "info-master") == 0)
    {
      mySerial.write("master\r\n");

      digitalWrite(GREEN_LED, !digitalRead(GREEN_LED));
    }
    else
    {
      while(Radio.busy());
      Radio.transmit(ADDRESS_BROADCAST, (unsigned char*) buffer, 50);
 
      while(Radio.busy());
      if(Radio.receiverOn((unsigned char*) buffer, 50, 1000) > 0)
      {
        mySerial.write(buffer);

	digitalWrite(RED_LED, !digitalRead(RED_LED));
      }
    }
  }
}

here's the slave's code:

#include <SPI.h>
#include <AIR430BoostETSI.h>

void setup()
{
  Radio.begin(0x10, CHANNEL_1, POWER_MAX);

  Serial.begin(9600);
  Serial.setTimeout(1000);

  pinMode(RED_LED, OUTPUT);
  pinMode(GREEN_LED, OUTPUT);
  digitalWrite(RED_LED, HIGH);
  digitalWrite(GREEN_LED, HIGH);
}

char buffer[50];
int i;

void loop()
{
  while(Radio.busy());
  if(Radio.receiverOn((unsigned char*) buffer, 50, 1000) > 0)
  {
	if(strcmp(buffer, "info-slave") == 0)
	{
   	  strcpy(buffer, "slave\r\n");

	  digitalWrite(GREEN_LED, !digitalRead(GREEN_LED));
	}
	else
	{
          while(Serial.available())
            Serial.read();
  
	  strcat(buffer, " ");
	  Serial.write(buffer);    
	  Serial.flush();

	  for(i = 0; i < 50; i++) 
	    buffer[i] = 0x00;
		  
	  Serial.readBytesUntil('\n', buffer, 50);
		
	  if(strlen(buffer) > 0) 
	  {
	    strcat(buffer, "\n");
			
	    digitalWrite(RED_LED, !digitalRead(RED_LED));
	  }
	  else strcat(buffer, "\r\n");
    }
	
    while(Radio.busy());
    Radio.transmit(0x01, (unsigned char*) buffer, 50);
  }
}

any help will be appreciated,

thank you in advance.

 

hope the corrected version of this code will help someone else in the community.

Share this post


Link to post
Share on other sites

Hi,
I've run into some problems with the Anaren library and the CC110L module. I have not had the time to dig very deep, but for me it crashes consistently when there are bit errors (e.g. due to interference or receiving near the sensitivity limit). When I had a very good link, it seems very stable. Could be related to what you see. Here's what I did, and something you could look into:

 

Made a quick test mock up where I put the whole TX system (including batteries, no protruding wires!) in a closed tin can, and placed the RX in the next room, where I got about 50% packet error rate. The RX now crashed consistently every 10 - 20 packet, so I could debug. I got so far as to notice that the number of bytes returned by the Radio.receiverOn function by far exceeded the declared number of transmitted bytes. In my test program I transmitted 10 bytes, but when I started getting bit errors (the CRC was 0), the RX figured it received up to 10k bytes, and then crashed. This was as far as I got, but I suspect the huge number of received bytes messes up the data memory.

 

Cheers,

Paal

Share this post


Link to post
Share on other sites

Just a quick update on the issues I described above, if someone stumbles by :)

I was able to trace down the cause for the crashes I had when the receiver was operating at its sensitivity level (weak signal). It was indeed related to the "packet length byte" associated with the data payload getting corrupted.

 

After some poking around in the AIR library I found that that the CC1101 packet length configuration was set to 61 bytes. In my sketch I had only reserved 10 bytes in data memory for RX data, because I was only sending 10 bytes. My confusion around that was that with the AIR library, you specify in your sketch how many bytes you are receiving each time. I had set this value to 10, believing that the packet handling then would be done using this value. I was wrong, under the hood of the AIR library, it was still accepting packets up to 61 bytes long.

 

So every time the lengt byte was corrupted to a value between 10 and 61, some other data was overwritten by junk (packets with lenght byte > 61 bytes is automatically discarded by the CC1101 packet handler with the AIR library).

 

The simple fix was of course to increase the rxdata space to 61 bytes, I had a simple application and using the G2553 with enough RAM. Doing this, I got what seemed like a rock stable application even at an RF level where most of the packets was corrupted due to poor signal to noise ratio.

 

Not terribly happy with the AIR library, but I guess it wasn't really made for tinkering too much, just running the example sketches as is...

 

Edit: I see that the OP has made the same mistake as I did, he is only reserving 50 bytes in data memory for RX data. So his application will be more stable than mine, because its only packages with length between 50 and 61 that will crash his application.

Share this post


Link to post
Share on other sites

dear Paal,

I'd really want to thank you for your contribution.

 

I solved the problem in mid July by reserving 100 bytes for RX data.

It has been a rather empirical solution, your explaination is really appriciated.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...