Problem running the example on two launchpads with g2553s

[arware]

Hi, I've loaded the examples into two launchpads with g2553s Rx and Tx, and can't seem to run them properly. The first byte makes through OK, turning the green LED ON on the Rx LP, but the transmitter hangs in INVALID mode and does not recover. I have tried both USCI_A and USCI_B - same result. With USCI_B I actually transmitted one byte captured by the Tx LP from UART (putty) and displayed on putty connected to UART on the Rx LP. But still the same isue, first byte goes through, then Tx hangs... Is there a chance you could help? Arsen Norman

[arware]

I have tried the other pair of code, send-pushbtn-cmd.c and recv-pushbtn-cmd.c, same effect. It works for the first reboot and run on TX, then stops. I have noticed something weird though, the inline void pulse_ce() would cause an error in Code Composer Studio 6, which I fixed by removing the 'inline'. This tells me that there might be something unique with CCS! My guess is that Spirilis mostly develops using gcc? There might be something with optimization or it's absence that makes the code to freeze. I'd like to get to the bottom of this, if possible.

[spirilis]

Yes I only develop with GCC. Haven't fully tested this on CCS although I've heard it works, that said, the last person to tell me that may have been using CCS5.

[spirilis]

See if it works with the RedHat GCC (4.9) in CCS6?

[arware]

Will transmitter in ike-uscia-xx example operate properly on it's own, or it requires a receiver to respond? In my case the RED led comes up on the Transmitter, but it manages to send the first byte, because I see the GREEN LED on the receiver side, and when I reboot the Tx, the LED on the RX changes to RED and so on with every reboot of the Tx. I do watch the bit pattern on MOSI lines for both devices with the scope and Logic8, and they seem consistent.

[spirilis]

With the ike examples, are you making sure to use the USCI_A ports for SPI instead of B? The Green LED in particular conflicts with the MISO pin on the USCI_B SPI port.

[arware]

Yes, it's on USCI_A. And I changed to NO_OPTIMIZATION, just in case.

[spirilis]

Ok so with those examples, they are running at 1Mbps so AUTOACK should function, in which case yeah the RED LED on the TX means that RF24_IRQ_TXFAILED somehow got set. That would happen if the receiver is turned off or out of range.

Ordinarily the TX node should keep running, show a green LED all the time (indicating that the packets it's sending are being ACK'd correctly), and the RX node should see its red & green LEDs flashing alternately. I did not write the ike examples and I believe the library has gone through a couple revisions since, but in theory I think those examples should still work.

So what you're seeing is the TX node gets a red LED, the RX node might light up an LED once or so, but then it freezes?

[arware]

That's exactly correct. The Tx 'fails' after the first transmission, the Rx get's the first byte and flips the LED. Once the Tx is rebooted, the Rx flips the LED again. The Tx is consistently sends the first byte and 'fails'.

[spirilis]

What's weird is that the RX side is flipping. In theory it should keep getting set to the same value each time the TX is rebooted.

[arware]

Just verified to be sure: it does. Not very consistently, but it does. I moved Tx and Rx are from 6" to 3' apart, same result. Similar result were with ...-pushbtn-cmd example. Tx fails after first byte sent. TeamViewer is an option... as far as getting the latest version of the code (since I'm new to GitHub): From the https://github.com/spirilis/msprf24 I used [Download ZIP] button on the right side.

[spirilis]

Yeah that should be correct. I don't have my G2 launchpads handy unfortunately else I could test this myself.

[arware]

I used w_tx_payload_noack(); and it works. Enough for my project, but would be nice to have it fixed eventually. Very nice lib, btw! Thank you very much for it and for detailed response!

[spirilis]

No problem! Now I need to go test the autoack stuff better :)

[pbochenski]

Hello spirilis, I have the same problem and it also works with w_tx_payload_noack(). I could work on the examples if you tell me what might be wrong. is it pipe setting, or maybe FEATURE register needs to be set to enable auto ack? awesome library btw

[spirilis]

Pipe setting looks good to me. Looking at the datasheet, I can't find anything specifically wrong with what the examples are doing. Are all of you using cheap modules from ebay or aliexpress? (that's all I ever use too, but I do wonder if some of the SI24R1 or mislabeled cheap nRF24L01+'s just don't support autoack properly)

[pbochenski]

I use aliexpress ones. It is written nrf24L01+ on it but who knows if it's genuine. Thanks for help anyway.

[arware]

Genuine nRF24L01+ in my setup. The old school 10 piner.

[arware]

Hello spirilis, Did you have a chance to look at the code to figure out what is wrong (might not be wrong at all) with autoack option?

[mx201er]

Good Afternoon, I was just wondering if anybody has ever figured this out? I just ran across the exact same problem: it transmits the first packet and lights up an LED on the receiver, but then the transmitter lights up the red LED and it appears to hang. If I repeatedly power my transmitter up and down, it'll usually toggle lights on the receiver (once each power cycle).

I've tried to work through it in debug mode, but it appears to be a problem with the actual module? I used r_reg(0x07) and looked at bit 4, the transmitter definitely isn't receiving an ACK. I included w_reg(0x07,BIT4) to forcibly clear the MAX_RT bit and then read back the register to verify it has cleared, but it still didn't continue to send another packet. I'm not looking at it right now, but IIRC one thing I noticed when reading Address 0x07, is that the 7th bit is 1, when the manual says "Reserved - Only '0' allowed."

I appreciate the suggestion of using w_tx_payload_noack(), I may be able to make this work for this project.

Using the newest version of CCS, transmit as a standalone MSP430G2553 in a breadboard, and receive in a launchpad. Thanks in advance.

[GodOfCows]

First, amazing library, second the issue is most certainly the NRF24l01. I had the exact same problem word for word as arware. After about 3 hours of troubleshooting, I remembered in the beginning I had put the positive to ground and the ground to 3.3v for only 5 second before I realized my mistake. After changing the NRF24l01 for unopened ones, it works. My guess is that the NRF24l01 as a common weak point. I would recommend changing the NRF24l01 for anyone that is reading and see if that works.