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

Thread: Teensy LC with nrf24l01 Issue

  1. #1

    Teensy LC + nrf24l01 = BRICK

    Hey all,

    I've got an nrf24l01 wireless sketch running smoothly between two T3.1's. I'd like to change the transmitter to a Teensy LC, but have found that simply dropping the new board into the system doesn't work. In fact, loading the transmitter sketch onto the TLC bricks it, so that it doesn't make it into the main loop. **I found that the line that's bricking the TLC is radio.openReadingPipe() . I'll look at the library source but it might be beyond me.

    The library I'm using is recommended here:https://forum.pjrc.com/threads/24307...ht=nRF24L01%2B

    ************EDIT
    As far as I've been able to discern, this is the method that bricks TeensyLC:

    Code:
    void RF24::openReadingPipe(uint8_t child, uint64_t address)
    {
      // If this is pipe 0, cache the address.  This is needed because
      // openWritingPipe() will overwrite the pipe 0 address, so
      // startListening() will have to restore it.
      if (child == 0)
        pipe0_reading_address = address;
    
      if (child <= 6)
      {
        // For pipes 2-5, only write the LSB
        if ( child < 2 )
          write_register(pgm_read_byte(&child_pipe[child]), reinterpret_cast<const uint8_t*>(&address), 5);
        else
          write_register(pgm_read_byte(&child_pipe[child]), reinterpret_cast<const uint8_t*>(&address), 1);
    
        write_register(pgm_read_byte(&child_payload_size[child]),payload_size);
    
        // Note it would be more efficient to set all of the bits for all open
        // pipes at once.  However, I thought it would make the calling code
        // more simple to do it this way.
        write_register(EN_RXADDR,read_register(EN_RXADDR) | _BV(pgm_read_byte(&child_pipe_enable[child])));
      }
    }
    **************


    If it helps, here is the transmitter test sketch I'm using:
    Code:
    #include <stdio.h>
    #include <EEPROM.h>
    #include <SPI.h>
    #include <RF24.h>
    
    //radio stuff
    RF24 radio(7, 8); 
    const uint64_t pipes[3] = { 0xF0F0F0F0E1LL, 0xF0F0F0F0D2LL, 0xF0F0F0F0C3LL };
    
    byte noteOnCommand = 0x90;
    byte noteOffCommand = 0x80;
    elapsedMillis testTimer;
    boolean testFlip = true;
    
    void setup (){
      
      Serial.begin(9600);
      
      radio.begin();
      
      radio.setRetries(15,15);
      radio.setPayloadSize(2);
      radio.setChannel(0x4c);
      radio.setPALevel(RF24_PA_MAX);
      radio.setDataRate(RF24_250KBPS);
      radio.openWritingPipe(pipes[0]);
      radio.openReadingPipe(1,pipes[1]);//this line locks up the teensyLC
      radio.powerUp();
      radio.startListening();
     
      testTimer = 0;
    }
    
    void loop(){
      
      if(testTimer >1000){
        
        if(testFlip)
          noteOnWirelessRelay(noteOnCommand,90);
        else
          noteOnWirelessRelay(noteOffCommand,90);
        
        testTimer = 0;
        testFlip = !testFlip;  
      }
    }///////END OF MAIN LOOP
    
    
    void noteOnWirelessRelay(byte koomand, byte note){  //sends a message for a single note on
        
        byte payload[] = {koomand,note};
    
        radio.stopListening();
        bool ok = radio.write( &payload, sizeof(byte)*2 );
        radio.startListening(); 
    }
    Thanks for any assistance!
    Last edited by Electric Potato; 12-02-2015 at 07:54 PM.

  2. #2

    Solved it

    Well, I solved the problem for my current device by just removing the line "radio.openReadingPipe()" from setup(). Simple enough. I hadn't really tried running the full system without that line because I assumed from prior experience that it wouldn't work...I thought that the reading pipe was used to receive confirmation packets from the receiver via autoAcknowledge without which it would hang.
    So at any rate, anyone know why that line has to be removed? Does it have something to do with the non-FIFO serials on the LC? I'm pretty dense when it comes to low level hardware...

  3. #3
    Junior Member
    Join Date
    Jan 2019
    Posts
    2
    Hello,

    I hate to grave dig but this is only relevant thread I have found. Are there any suggestions on why the Teensy LC differs from an UNO when running the RF24 library for the NRF24L01+?
    I use the same pins and same sketch but it doesn't work on the Teensy LC. I even tried changing the SPI clock speed divider as recommended. I also put in a decoupling capacitor and checked the power on an oscilloscope.

    NRF42 --- Teensy
    GND ---- GND
    VCC --- 3V3
    CE -- 9
    CSN -- 10
    SCK -- 13
    MOSI - 11
    MISO -- 12
    IRQ -- Not Connected

    I've attached some picture of my board (google drive link below). The few code samples I have found including the library's example code works fine on two Unos, but not on a Teensy LC.

    https://drive.google.com/drive/folde...i9?usp=sharing

    Please let me know any suggestions.

    Thanks,
    Ryan

  4. #4
    Senior Member
    Join Date
    Sep 2015
    Location
    Taiwan, Asai. (Traditional Chinese)
    Posts
    148
    Hi guys, I recently just met some problem with that related,

    from my experience the nrf module could not run faster than 8Mhz,
    I once had a uno run at 24Mhz, that divides to 12Mhz to SPI I guess?
    and the module can do not more than successful begin(), other function that wait for any data bricks.
    not sure how fast will LC , but make sure 48Mhz is divided to somewhere lower than 10Mhz (by datasheet)

    Second is that the 3.3V provider must be very stable?
    I used a HT7333 on my own board and it didn't work properly,
    but a HT7333 module from the market with 0.1uF+1.2uF at input / 0.1uF at output ,
    (the capacity value is from my meters and probably not very correct)
    after some desolder and part switching, I'm confident that the capacitors played a role, and it needs correct value rather than big values.
    As your Uno works fine, you can probably borrow 3.3V from Uno board.

    Also you can try switch another module or two, sometimes there are just bad modules and bad luck. :\
    sometimes its bad wire( SPI wire), too long or something, kinda socery.

    I'm also planning on using LC on a future (and even onboard 3.3V) so hope my tips help and I can learn from you reply

  5. #5
    Junior Member
    Join Date
    Jan 2019
    Posts
    2
    Quote Originally Posted by Po Ting View Post
    Hi guys, I recently just met some problem with that related,

    from my experience the nrf module could not run faster than 8Mhz,
    I once had a uno run at 24Mhz, that divides to 12Mhz to SPI I guess?
    and the module can do not more than successful begin(), other function that wait for any data bricks.
    not sure how fast will LC , but make sure 48Mhz is divided to somewhere lower than 10Mhz (by datasheet)

    Second is that the 3.3V provider must be very stable?
    I used a HT7333 on my own board and it didn't work properly,
    but a HT7333 module from the market with 0.1uF+1.2uF at input / 0.1uF at output ,
    (the capacity value is from my meters and probably not very correct)
    after some desolder and part switching, I'm confident that the capacitors played a role, and it needs correct value rather than big values.
    As your Uno works fine, you can probably borrow 3.3V from Uno board.

    Also you can try switch another module or two, sometimes there are just bad modules and bad luck. :\
    sometimes its bad wire( SPI wire), too long or something, kinda socery.

    I'm also planning on using LC on a future (and even onboard 3.3V) so hope my tips help and I can learn from you reply
    Hi,

    Thanks for the tips.

    1) I do not know if the SPI divider code is working. I tried different dividers with the same results including 4,8,16, and 32.

    2) I verified it on an oscilloscope with and without a capacitor. The supply looks smooth as can be.

    3) I built another teensy+nrf24 board with the same results. The first one was all soldered, and the second was jumper wires like the two Unos. An image of the solder job is posted in my previous post in the google link.

    Please let me know if you can get it working; I'd love to see your wiring including capacitors if any, as well as the code you used.

    Thanks again,
    Ryan

  6. #6
    Senior Member
    Join Date
    Sep 2015
    Location
    Taiwan, Asai. (Traditional Chinese)
    Posts
    148
    my LC&nrf works fine with direct power from 3.3V on LC and pin 8,9 as CE/CSN, 11,12,13 as SPIs, 15 as IRQ.

    I first thought it was related to capacitors , but not all cases?

    my code first didn't work as reciever but works fine as transmitter
    by accident I discover this:
    I don't sure why, but adding a delay(1); after radio.startListening(); and before radio.available();
    also solves my problem that it cannot recieve.
    by testing it needs about delayMicroseconds(500); to reach some kind of stability or else it returns false at the moment,
    and my code contains stopListening in the same cycle afterwards so it never recieves at any cycle.
    this could be the same problem of yours.
    Can also did the same by waiting the IRQ pin to pulldown before calling radio.available();

    I looked into the tmrh20 source code, but I couldn't find anything related
    " http://tmrh20.github.io/RF24/RF24_8c...ce.html#l01218 "

    other FYI : removing the 1M resistor on the NRF24 module does nothing,
    removing the 22pf of the crystall, it still can transfer data, but cannot recieves.

    you can directly power the nrf24 module with lithium battery / 5V , but side effect: after powering for few hours or more, the chip was permanently damaged and always draw an extra ~2mA at all mode including Powerdown, besides this the module works totally fine however.
    I didn't power the chip for more time, because a power leak at mA wasn't what my project can accept. So I can't say if it goes further leaking or burning at longer period.

    I did these for curiosity, and to find out if it was stable, so I can make convenient layouts with less part and maximum laziness.
    some of the COB nrf modules in market are missing some of the components and works fine, so I'm guessing some are maybe unneccessary.

    Hope my findings help you

Posting Permissions

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