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

Thread: Dropping in 3.2 for LC-designed project - any gotchas?

  1. #1
    Junior Member
    Join Date
    Aug 2019

    Dropping in 3.2 for LC-designed project - any gotchas?

    Hi, I am checking to see if I'm missing something dumb/obvious. If it comes down to it I can post code, but I'm first just hoping this might be a simple solve that someone already knows...

    I'm using a Teensy 3.2 in a project I've previously built with LCs. It uses NRFlite in SPI mode to tx/rx data, and I've already built 20 of these using LCs with no problem. I just dropped in the 3.2 for the first time and now it's telling me it can't find the radio. It's not super easy to tell why, but I'm digging in; I've tested the nRF24L01+ module, it's good, and the Teensy is otherwise working as expected. Is there -anything- different about how it handles SPI, could the faster speed be causing an issue?

    (I did find this:

    Thanks in advance,

    PS some other specs: it's on a PCB, so probably not a wiring problem. The radio is socketed, so I was able to swap out and test others (and it test good in another socket) but unfortunately the Teensy itself is not socketed, a little harder to get out for testing elsewhere

  2. #2
    Senior Member
    Join Date
    Dec 2014
    Are you using the +5V output pin of the LC? That pin is not the same on the 3.2.

    Other than that, hook up your logic analyzer or oscilloscope to figure out what the difference is...

  3. #3
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Ayer Massachussetts
    Well the 3.2 typically runs at 96Mhz, and the LC tops out a 48Mhz. Perhaps the Teensy 3.2 is running to fast for the device.

    Perhaps you need pull-up resistors on the CS pins.

    Perhaps you have a connection issue or cross wiring.

    Some pins are different. For example, the LC has a second SPI bus and the 3.2 does not. I have a summary where I try to compare the various Teensy's:

    As jwatte mentions, what is normally VBat on the 3.2 is pin 17 converted to 5v.

    The DAC pin changes pin number from A14 (3.2) to A12 (LC).

  4. #4
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    As a first quick sanity check, try setting Tools > CPU speed to run Teensy 3.2 at only 24 MHz. Even at half the clock speed, it still might be faster than Teensy LC. The M4 processor is much more capable than the M0+. But 24 MHz should get you pretty close.

  5. #5
    Junior Member
    Join Date
    Aug 2019
    Thank you everyone for your responses! Really appreciate the help.

    Paul: Great news - I tested with the 3.2 running at 24mhz (and also 48Mhz), and the radio responded OK, so this is definitely an issue of running too fast for the NRFLite library and/or the device itself. Or so I thought, because then I bumped it to 48 and 72 and it still worked... Now I can't actually get the radio to fail, even at 96! (But I still think that the original issue was a matter of clock speed, so I'm going to stay underclocked.)

    jwatte/Michael: ouch. I didn't notice the VBat vs 17-at-5V difference. For some reason I thought the 3.2 did the same voltage upconversion. I -am- using that in the LC to power some LEDs. And since this is mounted on a PCB, that means there's a trace connecting my LED data out to what is now vBAT. I can modify this particular PCB to connect the true data pin (1, which I had jumpered to 17) to the LED out, and see if 3.3v is enough to drive the pixels or whether I lose that first one. But do you think there will be any issue with the additional connection from a data pin to vBat?

    [And thanks Michael, I'm just using the primary SPI and not relying on any of the extra capabilities of the 3.2.]

Tags for this Thread

Posting Permissions

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