Pin 13 Problem on Teensy 4.1

Status
Not open for further replies.

MeBoop

Member
Hi! I'm seriously enjoying my 4.1, but I've run into a bit of a conundrum. My pin 13 is very noisy and only goes up a couple millivolts (confirmed via scope) when I set it to HIGH. This is particularly problematic because SCK is on this pin and I need to use both SPIs (as I'm reserving SPI1 to a device that annoyingly isn't tri-state).

Does anyone have any insight as to why this might be? All the other pins work fine and without issue except fro this one. An acceptable workaround if its even possible would be to use a different pin for SCK on SPI(0), but I don't think that's possible.

Thanks!
 
Hi,
Can you show us the code and the hardware connected to the Teensy 4.1 that results in the millivolt output on pin 13?
When I connect a scope to pin 13 while running the >Examples>Teensy>Tutorial1>Blink sketch, I see a perfect waveform:

SDS00001.png

Thanks,
Paul
 
My pin 13 is very noisy and only goes up a couple millivolts (confirmed via scope) when I set it to HIGH.
You cannot manipulate Pin13 after initializing SPI. So you cannot set it to high by digitalWrite or by using pinMode.
 
You cannot manipulate Pin13 after initializing SPI. So you cannot set it to high by digitalWrite or by using pinMode.

I'm aware -- SPI not functioning is how I figured out this was happening in the first place

Hi,
Can you show us the code and the hardware connected to the Teensy 4.1 that results in the millivolt output on pin 13?
When I connect a scope to pin 13 while running the >Examples>Teensy>Tutorial1>Blink sketch, I see a perfect waveform:

View attachment 20658

Thanks,
Paul

I'm using the blink sketch here -- look how wonky the signal is.
Screenshot_2020-06-20 Instrument Control.png

For reference, here's blink on pin 14:
Screenshot_2020-06-20 - Working - Instrument Control.png
 
For what it is worth, here is a capture on a T4.1 with my Saleae Pro Logic 8 digital in white, analog in Blue...

screenshot.jpg
 
I think my pin may just be foobarred :(

So I don't have to wait for a replacement to ship, does anyone have a suggestion on "soft coding" a circumvention for the non tristate SPI board I'm interacting with? For instance, could I do something really dumb like swap my MISO1 pin back and forth from 39/1 depending on if I'm communicating to the device or not? Not sure how that would behave, performance wise, but this isn't a performance critical application (e.g. I'd only render to the display when enough changes happened, etc)
 
In many cases like this, the first thing I try, is to make sure there is a good solder joint and also that there is not a solder bridge to another pin...

I can probably look it up, but I know @mjs513 has display boards setup to tristate the MISO pin Maybe something like a 74AHC1G125GV

Other option, might be, I have a FlexIO version of SPI, that is up github, that was working for some stuff, but it does not use the same base class as SPI, so not as easy to drop in.

You also have SPI2, but those pins are not easy to get to. Either on the SDCard or the bottom memory chips.
 
In many cases like this, the first thing I try, is to make sure there is a good solder joint and also that there is not a solder bridge to another pin...

I can probably look it up, but I know @mjs513 has display boards setup to tristate the MISO pin Maybe something like a 74AHC1G125GV

Other option, might be, I have a FlexIO version of SPI, that is up github, that was working for some stuff, but it does not use the same base class as SPI, so not as easy to drop in.

You also have SPI2, but those pins are not easy to get to. Either on the SDCard or the bottom memory chips.

Aw man, double checked the solder joint and I'm not shorting it, that would've been a huge relief. At this point I might just order another teensy, would prefer that to using an additional chip to babysit the rude display driver -- esp. since I intend on shoving some of the SOIC8 PSRAM to house a framebuffer (which at this point I may should just scrap the RAIO, since its disappointingly slow and flickery, and the text mode is slightly buggy.)

If I do stick with the RAIO I'll have to see about porting slumdog's library to the 4.1, or writing my own (I'm willing to bet the 4.1 is more than capable enough to handle freetype, for example.)

Thanks for everyone's help, I think I'll just consider this a defeat for now.
 
Update since I can't edit my post(?) -- The WINC1500 WiFi module I'm using seems to behave despite the RA8875 not being tristate and there has been no issues after running both in tandem for ~an hour (just outputting WiFi scan results to screen) -- so if anyone else runs into this issue with this particular setup, you should be good to go using SPI1.
 
Status
Not open for further replies.
Back
Top