spirilis

[Energia Library] Nordic nRF24L01+ library

349 posts in this topic

For weeks now, I have been trying to interface my MSP430G2553's with nRF24l01 transceivers. The sample code for the receiver seems to be working alright. I was able to measure the pin voltages and monitor the current draw of the receiver. However, the transmitter doesn't seem to be working as expected. The CE pin will not go high. Even if I force it high, the transmitter will not draw any current. The only thing I did to change the code was to add a few lines for a flashing LED. This is to ensure that the microcontroller is active when used as a standalone. Here's the code:

#include <SPI.h>
#include <Enrf24.h>
#include <nRF24L01.h>
#include <string.h>


Enrf24 radio(P2_0, P2_1, P2_2);  // P2.0=CE, P2.1=CSN, P2.2=IRQ
const uint8_t txaddr[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0x01 };

const char *str_on = "ON";
const char *str_off = "OFF";

void dump_radio_status_to_serialport(uint8_t);

void setup() {
  Serial.begin(9600);

  SPI.begin();
  SPI.setDataMode(SPI_MODE0);
  SPI.setBitOrder(MSBFIRST);

  radio.begin();  // Defaults 1Mbps, channel 0, max TX power
  dump_radio_status_to_serialport(radio.radioState());

  radio.setTXaddress((void*)txaddr);

//MY ADDITION TO THE CODE (FLASHING LED). THIS ENSURES THE MICROCONTROLLER IS READY/ACTIVE.
   pinMode(P1_0, OUTPUT);
   digitalWrite(P1_0, LOW);
   int x=0;
   volatile int state = HIGH;
   volatile int flag = HIGH;
  digitalWrite(P1_0, state);
  while(x<15)
  {
  digitalWrite(P1_0, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(100);               // wait for a 1/10th second
  digitalWrite(P1_0, LOW);    // turn the LED off by making the voltage LOW
  delay(100);               // wait for 1/10th second
  x=x+1;
  }

//END FLASHING LED


}


void loop() {
  Serial.print("Sending packet: ");
  Serial.println(str_on);
  radio.print(str_on);
  radio.flush();  // Force transmit (don't wait for any more data)
  dump_radio_status_to_serialport(radio.radioState());  // Should report IDLE
  delay(1000);

  Serial.print("Sending packet: ");
  Serial.println(str_off);
  radio.print(str_off);
  radio.flush();  //
  dump_radio_status_to_serialport(radio.radioState());  // Should report IDLE
  delay(1000);
}

void dump_radio_status_to_serialport(uint8_t status)
{
  Serial.print("Enrf24 radio transceiver status: ");
  switch (status) {
    case ENRF24_STATE_NOTPRESENT:
      Serial.println("NO TRANSCEIVER PRESENT");
      break;

    case ENRF24_STATE_DEEPSLEEP:
      Serial.println("DEEP SLEEP <1uA power consumption");
      break;

    case ENRF24_STATE_IDLE:
      Serial.println("IDLE module powered up w/ oscillators running");
      break;

    case ENRF24_STATE_PTX:
      Serial.println("Actively Transmitting");
      break;

    case ENRF24_STATE_PRX:
      Serial.println("Receive Mode");
      break;

    default:
      Serial.println("UNKNOWN STATUS CODE");
  }
}

Eliminating the flashing LED doesn't solve the problem.

Other symptoms vary depending on if the IC is on the launchpad or standalone. On the launchpad, the CE and MISO pin remain at about half supply voltage. Standalone, they remain low. The most significant observation (only happens for standalone) is that the MOSI pin stays at 3.3V as expected, but pulses toward 0V every second or so repeatedly. During this short pulse duration, the transceiver tries to draw some current, but then shuts off immediately. The CE pin remains low for the most part. However, I was able to get a measurable voltage (in the mV range) during this odd pulse time.

If I am correct in my assumptions, hardware setup remains the same between receiver and transmitter. Any help here would be greatly appreciated.

Share this post


Link to post
Share on other sites

Or possibly, the transmitter is only supposed to draw current during the short time when it transmits a bit? In that case, it is working correctly from an electrical perspective. However, the overall system doesn't work. There is no response from the receiver. Being completely new to all of this, I don't know where to take it from here?

Share this post


Link to post
Share on other sites

I have used this library with both custom MSP430G2553 boards and the LaunchPad.  Hardware setup is the same whether receiver or transmitter.  Among the possible problems and solutions are the following:

  • Bad nRF24 - the very first one I bought was bad
  • damaged pin on MSP430 - don't apply 5V to a pin - this is a 3V3 device
  • nRF24 wired wrong or wrong pin in software - easy to do
  • poor transmission between modules - too far apart, object in between, or even too close together.
  • modules set on different channel or other incompatibility in way software is set up

In general though, I  have found the library easy to use and reliable.  I suggest you concentrate on getting the examples working first without any modification.  I haven't tried it with Energia V18, you might try Energia V17.  The following are the pins I normally use:

  nRF pin  pin#    Std color   F5529LP pin   G2553 pin
  -------  ----    ---------   -----------   ---------
  Vcc         1    Red         3V3           3V3      
  GND        20    Black       GND           GND      
  CSN         9    Yellow      P4.2          P2_1     
  CE          8    Green       P2.7          P2_0     
  MOSI       15    White       P3.0          P1_7      
  SCK         7    Orange      P3.2          P1_5      
  IRQ        10    Brown       P4.1          P2_2      
  MISO       14    Purple      P3.1          P1_6     

I use the same wire color every time to ease checking that the connection is correct.

If CE is not going high then try setting up a simple pin toggling program (e.g. the "hello world" pin wiggling and check with multimeter) to see if it works without the library.  This will tell you if the CE pin on the MSP430 has been damaged.  If so, changing to a different pin will fix it until you get a new $2 chip.

EDIT:  Some multimeters can be quite slow to update.  When toggling pins to see if they are reaching a full on state, keep the toggling frequency to 1 Hz so the meter can keep up.  For monitoring an application like the one above an oscilloscope or logic analyzer is a better tool.

Edited by Fmilburn

Share this post


Link to post
Share on other sites

I did try switching the IC codes. Still, whichever chip the transmitter code is on, the CE pin will not go high and will not activate. Either chip will work fine with the receiver code. I also tried switching the nRF21L01's, but still could not isolate the problem to any specific piece of hardware. Should the CE pin be high on the transmitter? I noticed, during the short duration when it is transmitting a bit, the CE pin briefly pulses high, but only barely in the mV range.

 

Also, the transmitter code is supposed to send two bits in the loop. This brief pulsing effect seems to happen when transmitting each bit. I know this because I added the flashing LED code to the end of the loop to indicate when it is cycling back to the beginning of the loop. I get two shorts pulses (One pulse: 3.3V to 0V and back to 3.3V on the MOSI pin) before the LED flashes. Then, it cycles back, emits 2 short pulses, flashes the LED, and so on.

Here's the modified loop code:

void loop () {

  Serial.print("Sending packet: ");
  Serial.println(str_on);
  radio.print(str_on);
  radio.flush();  // Pulsing on MOSI pin (3.3V to 0V and back to 3.3V)
  dump_radio_status_to_serialport(radio.radioState());  // Should report IDLE
  delay(1000);
  Serial.print("Sending packet: ");
  Serial.println(str_off);
  radio.print(str_off);
  radio.flush();  // Pulsing on MOSI pin (3.3V to 0V and back to 3.3V)
  dump_radio_status_to_serialport(radio.radioState());  // Should report IDLE
  delay(1000);
  int x = 0;
   while(x<15)
  {
  digitalWrite(P1_0, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(100);               // wait for a 1/10th second
  digitalWrite(P1_0, LOW);    // turn the LED off by making the voltage LOW
  delay(100);               // wait for 1/10th second
  x=x+1;
  }
 
}

 

By the way, I did try Energia 17 and 18 with the same results.

Share this post


Link to post
Share on other sites

How do you know it works as a receiver if you don't have anything working as a transmitter - what are you receiving without a transmission?  Have you gone back and double checked that one of my suggestions isn't the cause?  I can assure you that the library works when connected properly with the nRF24L01+ modules I have and a G2553 LaunchPad.

The datasheet for the nRF24L01+ has all the details and can be found with a google search - it uses SPI.  SPI keeps the chip select pin high until it is ready to transmit and then pulls it low.  It then returns to high following transmission.  The code for the library is in Enrf24.cpp.  Look inside at the code, e.g.

void Enrf24::_writeReg(uint8_t addr, uint8_t val)
{
  digitalWrite(_csnPin, LOW);
  rf_status = SPI.transfer(RF24_W_REGISTER | addr);
  SPI.transfer(val);
  digitalWrite(_csnPin, HIGH);
}

It pulls it low before transmitting then returns to high.

One more suggestion - if you do a search on the internet you will find various people have found this helps:  https://forum.arduino.cc/index.php?topic=376068.0  I include a decoupling capacitor in my designs and normally power the radio from a battery.  Nonetheless, I have also had success powering off of the LaunchPad.

Share this post


Link to post
Share on other sites

I don't know for sure if the receiver is actually working, but I do know that it is drawing a constant 14mA and the CE pin remains high. These IC's are from Mouser, which has had a problem in recent past with counterfeit parts, so new G2553's should be on order. I can try new nRF24L01's as well, but like I said, I mixed and matched different combinations of transceivers and IC's, all with the same result. I've also disconnected and reconnected the setup multiple times with the same result, so I'm fairly confident in the wiring.

I'm using a 20A power supply which has plenty of capacitance at the output, so it should be able to adequately power the nRF24L01 to transmit a couple feet for testing purposes.

"modules set on different channel or other incompatibility in way software is set up". This, I have not looked into and don't really know enough about it to check.

By the process of elimination, I have been leaning toward the SPI file being at fault. Where is a good place to find a SPI file? I can't even remember where I downloaded mine.

Share this post


Link to post
Share on other sites
1 hour ago, ghjkl67 said:

...By thee process of elimination, I have been leaning toward the SPI file being at fault. Where is a good place to find a SPI file? I can't even remember where I downloaded mine

SPI.h is part of energia if you got your spi from someplace else, it is probably wrong

Share this post


Link to post
Share on other sites

When I downloaded both versions of Energia, the Tx/Rx codes would not compile until I downloaded SPI to the libraries. Of course, this is assuming my memory serves me right.

Backing up a bit, I took the exact Tx code from github, loaded it on to both of my G2553's, and hooked them up to my two nRF24L01's. Same symptoms from both of them. So, either a piece of hardware is bad on both setups, or there's something wrong with the software. My guess is the software (meaning SPI).

"SPI keeps the chip select pin high until it is ready to transmit and then pulls it low.  It then returns to high following transmission." This is exactly what happens, only it's on the MOSI pin, not CSN.

Share this post


Link to post
Share on other sites
14 minutes ago, ghjkl67 said:

When I downloaded both versions of Energia, the Tx/Rx codes would not compile until I downloaded SPI to the libraries. Of course, this is assuming my memory serves me right.

I have no idea what you mean about both versions.  ... I just went to see what is offered I see a 1.6.10E18 version  of Energia are you running that?

/rant on

... man this new version of the forum is painful to use ... i just tried to quote .. and i have no idea how i eventually was able to edit after the quote ...

I used to have problems but there was an html option which is how i usually created posts ... seems to be gone ...

/rant off

I was going to post

 

Share this post


Link to post
Share on other sites

I tried to edit my post to include a quote. Then, I just gave up and typed quotes around it! Hopefully everyone will catch my drift.

Both versions meaning Energia 17 and Energia 18. As I type, I'm extracting the Energia 17 files to see if it already had the SPI file.

 

Share this post


Link to post
Share on other sites

$ pwd
/home/kimballr/energia-1.6.10E18/hardware/energia/msp430/libraries/SPI
$ ls
examples  keywords.txt    library.properties  SPI.cpp  SPI.h  utility
/edit ...
Sorry this is not the place to deal with SPI issues. You might resolve those before continuing to post in this thread about
/editoff

Share this post


Link to post
Share on other sites

Well, it looks like I was using the SPI file provided by Energia, so that's not the problem.

I find it interesting that the MOSI pin is behaving the way CSN should behave. Somewhere along the line, the pins must have been flipped in the software.

Share this post


Link to post
Share on other sites

@energia

I just tried compiling the nRF24L01 library in V18 and got the following error:

In file included from C:\Users\Frank\Documents\Energia\MSP-EXP430F5529\Enrf24_RXdemo\Enrf24_RXdemo.ino:16:0:

C:\Users\Frank\Documents\Energia\libraries\Enrf24/Enrf24.h:32:17: fatal error: SPI.h: No such file or directory

compilation terminated.

exit status 1
Error compiling for board MSP-EXP430G2553LP.

@ghjkl67

You should not have to add SPI.  Try using Energia V17 as I suggested above.  You will find it here under previous releases:  http://energia.nu/download/  Energia V18 still seems to have some bugs. I just flashed the sample code on two G2553s with nRF24L01s using Energia V17 and they are working fine.

EDIT:  I would remove the old versions of Energia before loading a new V17.

Edited by Fmilburn

Share this post


Link to post
Share on other sites

the problem is the example code there @fmilburn ... move the #include <SPI.h> ahead of the include <Enrf24.h>

...
#include <SPI.h>
#include <Enrf24.h>
#include <nRF24L01.h>

Enrf24 radio(P2_0, P2_1, P2_2);  // CE, CSN, IRQ pins
...

Fmilburn likes this

Share this post


Link to post
Share on other sites

Yes, I found that bug some time ago. At first, I must have tried reinstalling SPI before discovering the trick of moving it to the front of the code. Anyway, that's irrelevant, since I'm using Energia 17 now with the proper SPI file that came with it. Here is a photo with the corresponding pin wires below:

Blue: GND and VCC

Black: P2.0

Green: P2.1

Yellow: P1.5

Orange: P1.7

Brown: P1.6

Red: P2.2

47K from VCC to RST

LED is included just for the receiver.

A separate 330 ohm resistor is included to allow the power supply to drain faster.

 

G2553.jpg

Share this post


Link to post
Share on other sites

Yes, the blinking works fine. Most recently, I removed the blinking and loaded the exact code from github.

The brown and orange are in their correct locations. The picture can be misleading.

Everything works exactly the same on the launchpad. Before, I was getting 1/2VCC on some of the pins such as CE, but I think that's because the LED was still connected. Now, I disconnected it.

Adding a 0.1uF cap from VCC to GND does nothing. I make it common practice to put a cap from RST to ground though.

Share this post


Link to post
Share on other sites

I guess you are right then it must be the software.

I'm just surprised that the scores of other people haven't had this same problem.  @Fmilburn just tested with V17 it appears he is using some manner of windows.  I'm on linux and it seems to work fine.  Maybe it is a platform issue. 

Share this post


Link to post
Share on other sites

I've always had horrible luck with software. That's why I'm a hardware guy.

Probably my only bet now is to buy two new complete launchpads and start from scratch.

Still, I have to stress that the MOSI pin is behaving in exactly the same way the CSN pin should behave. Somehow, I think the pins got switched around in the code.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now