my Teensy 3 is having trouble taking any new code

Status
Not open for further replies.
neep

neep

Well-known member
I keep running into problems uploading to one of my Teensy 3s, whilst the other functions fine.

The main difference is one is built into a toy and the other is on a breadboard. I use the same USB cable and the same program, but the one on the breadboard always takes the upload while the other one doesn't.

They both have pretty much the same wiring to an SD reader and a WS2801 LED strip, although the one in the toy has the wires bundled close together, so I am thinking maybe there can be some crosstalk. Could that be it?

Sometimes it does work when I exit the IDE (beta 10), disconnect USB and do the reverse, but at some point it starts acting up again. It does show the "programming" window but then that appears to hang. In syslog there is this:

Code: 
Jan 29 00:56:18 pauls-MacBook-Pro-2 [0x0-0x1c01c].com.pjrc.teensy[209]: file changed
Jan 29 00:56:18 pauls-MacBook-Pro-2 [0x0-0x1c01c].com.pjrc.teensy[209]: File "AnalogReadSerial.cpp.hex". 7812 bytes, 6% used
Jan 29 00:56:18 pauls-MacBook-Pro-2 [0x0-0x1c01c].com.pjrc.teensy[209]: remote connection opened
Jan 29 00:56:18 pauls-MacBook-Pro-2 [0x0-0x1c01c].com.pjrc.teensy[209]: remote cmd: "comment: Teensyduino 1.11 - MACOSX"
Jan 29 00:56:18 pauls-MacBook-Pro-2 [0x0-0x1c01c].com.pjrc.teensy[209]: remote cmd: "dir:/var/folders/p6/n8_p41b974qf8dzx7r_8nb2m0000gn/T/build4850910739712455861.tmp/"
Jan 29 00:56:19 pauls-MacBook-Pro-2 [0x0-0x1c01c].com.pjrc.teensy[209]: remote cmd: "file:AnalogReadSerial.cpp.hex"
Jan 29 00:56:19 pauls-MacBook-Pro-2 [0x0-0x1c01c].com.pjrc.teensy[209]: File "AnalogReadSerial.cpp.hex". 7812 bytes, 6% used
Jan 29 00:56:19 pauls-MacBook-Pro-2 [0x0-0x1c01c].com.pjrc.teensy[209]: remote cmd: "status"
Jan 29 00:56:19 pauls-MacBook-Pro-2 [0x0-0x34b34b].cc.arduino.Arduino.teensyduino[15939]: Binary sketch size: 7,652 bytes (of a 131,072 byte maximum)
Jan 29 00:56:19 pauls-MacBook-Pro-2 [0x0-0x34b34b].cc.arduino.Arduino.teensyduino[15939]: Estimated memory use: 4,044 bytes (of a 16,384 byte maximum)
Jan 29 00:56:19 pauls-MacBook-Pro-2 [0x0-0x1c01c].com.pjrc.teensy[209]: status data sent
Jan 29 00:56:19 pauls-MacBook-Pro-2 [0x0-0x1c01c].com.pjrc.teensy[209]: remote connection closed
Jan 29 00:56:19 pauls-MacBook-Pro-2 [0x0-0x1c01c].com.pjrc.teensy[209]: remote connection opened
Jan 29 00:56:19 pauls-MacBook-Pro-2 [0x0-0x1c01c].com.pjrc.teensy[209]: remote cmd: "status"
Jan 29 00:56:19 pauls-MacBook-Pro-2 [0x0-0x1c01c].com.pjrc.teensy[209]: status data sent
Jan 29 00:56:19 pauls-MacBook-Pro-2 [0x0-0x1c01c].com.pjrc.teensy[209]: remote cmd: "status"
Jan 29 00:56:19 pauls-MacBook-Pro-2 [0x0-0x1c01c].com.pjrc.teensy[209]: status data sent
Jan 29 00:56:19 pauls-MacBook-Pro-2 [0x0-0x1c01c].com.pjrc.teensy[209]: remote cmd: "status"
Jan 29 00:56:19 pauls-MacBook-Pro-2 [0x0-0x1c01c].com.pjrc.teensy[209]: status data sent
Jan 29 00:56:19 pauls-MacBook-Pro-2 [0x0-0x1c01c].com.pjrc.teensy[209]: remote cmd: "status"
Jan 29 00:56:19 pauls-MacBook-Pro-2 [0x0-0x1c01c].com.pjrc.teensy[209]: status data sent

[repeat many times]

Jan 29 00:56:26 pauls-MacBook-Pro-2 [0x0-0x1c01c].com.pjrc.teensy[209]: remote cmd: "status"
Jan 29 00:56:26 pauls-MacBook-Pro-2 [0x0-0x1c01c].com.pjrc.teensy[209]: status data sent
Jan 29 00:56:27 pauls-MacBook-Pro-2 [0x0-0x34b34b].cc.arduino.Arduino.teensyduino[15939]: Please press the RESET BUTTON on your Teensy to upload your sketch.  Auto-reboot only works if the Teensy is running a previous sketch.
Jan 29 00:56:27 pauls-MacBook-Pro-2 [0x0-0x1c01c].com.pjrc.teensy[209]: remote connection closed

Pressing the reset button doesn't help either. This is really frustrating me, as I don't feel like taking the whole thing apart again. Any ideas?
 
So I found that whenever I upload some code that does anything with the SD adapter on the SPI interface, the whole thing locks up and it won't respond to the Teensy loader anymore...

is it possible that some badness going on in the SPI bus can get the Teensy to get locked up?
 
So the only thing that can get it to respond again to the loader is to totally disconnect the DOUT and SCK wires from the WS2801 strip. BTW should I use a resistor between those and the WS2801 strip? Could not using one be causing this?
 
So doing some tests using crocodile leads in between SCK and DOUT reveals me that there are some definite maximum lengths that the wires can become. When I use a 40cm crocodile lead in between, I'm unable to get a reading out of the SD card. When I do a short jumper, it' fine. I'm now starting to think this is a signal strength issue.

On my toy, the way I connect the Teensy SCK and DOUT is:

Teensy -> WS2801 strip -> (parallel connection on the same strip) -> SD adapter.

Could this cause too much impedance already?
 
I've done some more tests. When connect everything up on the breadboard, no problem. So this is:

SD adapter -- SPI -- Teensy -- SPI -- WS2801 strip

Connected to the CS wire between the Teensy and the SD adapter is the gate of a MOSFET, which then interrupts the clock signal for the WS2801 strip. If I don't do this the SD adapter is not able to read any card. But with the MOSFET, it is able to read okay.

However as soon as I start wiring everything really closely bundled together in a staff I'm making, I run into troubles. When I then run my program that first initializes both the strip and the SD card, and start doing seeks and reads followed by outputting to the strip using fastSPI, the Teensy often just locks up completely. Even to a point where uploading new compiles is not possible (the loader just gets not response from the Teensy). I then have to disconnect the clock and data wires from the strip, and power down the Teensy, repower it, and only then can I reprogram it.

It's really frustrating as everything works okay on a breadboard every time, but then runs into this problem when I start building it into the staff. So at this point I am thinking I need to shield the wires more perhaps. I am using basic jumper wire that I cut up for this purpose. Everything is really close together so maybe there is interference going on. I don't have a scope so it's hard for me to debug this.
 
This might be completely unrelated, but you might take a look at the waveform on the WS2811 thread.

http://forum.pjrc.com/threads/15620...tSPI_LED-library?p=20787&viewfull=1#post20787

Adding a 220 ohm resistor between the pin on Teensy 3.0 and the wire going to the LED strip greatly improved the signal quality and got rid of the terrible ringing effects.

It's hard to know if your problem is related, but adding 220 ohm resistors between the pins and wires is pretty easy to try.
 
It does indeed seem to make things better, but I need to do some more testing to see if the lockup problem is really staying away.

What baffles me though is that apparently a problem on the SPI bus (like a garbled data or clock signal interfering with being able to read from the SD card) can lock up the entire Teensy to a point where it doesn't respond to a reset from the loader. Is that to be expected?
 
Status
Not open for further replies.
Back
Top