Teensy 4.0 with odd boot problem

M

markkimball

Active member
I have a Teensy 4.0 that has started exhibiting an odd boot problem. I've been working on some code to implement two-way serial data transfers between the T4.0 and host computer, which is running Ubuntu 22.04LTS. I have several different versions of Arduino code to explore different approaches. Call them program A and B. When A runs, it runs once. After that one instance, the Teensy will NOT reboot program A. Unplug it, plug it back in -- no boot. But if I upload program B, the Teensy _does_ boot. Then if I go back and reload program A -- it _does_ boot. Until the code in loop() runs. Then it again will fail to boot.

This is an older T4.0 that's been reprogrammed a bunch of times. I'm wondering if the flash memory is starting to go bad, or if there's something else going on.

For a little more background information, I have attached a PJRC 320x240 TFT display to the T4.0 so I can debug code w/o relying on the serial interface. The setup() routine does run some code to print a message -- sort of an "I am here" message -- and no message appears.
 
Unlikely the flash would be going bad. It's good for something like 100,000 cycles. You should probably try just printing to the serial monitor instead of writing to your display, just to simplify things.
 
joepasquariello said:
Unlikely the flash would be going bad. It's good for something like 100,000 cycles. You should probably try just printing to the serial monitor instead of writing to your display, just to simplify things.
Click to expand...
The serial monitor was useful up to a point, but it interfered with the communication with the host -- it intercepted some characters, not all, depending on the timing. Very irregular and annoying until I figured out that I HAD to turn the serial monitor off in order to get well-formed data. So it's a non-starter in this case. The TFT display really helped out in this regard.

I may have had some nasty buffer overruns that over-wrote memory in some of my code versions but I don't see how effects from that could persist after a total powerdown. A puzzler, to me at least.

Just to make things even stranger, I was able to re-program and operate the Teensy multiple times with no problems -- until I unplugged it and plugged it back in. Then it went back to a no-boot condition. This is not due to some odd interaction with the Arduino IDE because it does the same thing with no IDE running. lsusb shows the Teensy is recognized as a teensyduino serial device so the OS knows it's there, too.

I only have the TFT device (and USB cable) connected to the teensy.
 
You might try DUAL USB for a debug on the second USB port.
USB Serial typical runs well until something crashes the USB code or interrupts that service it.
" Tools / USB Type: Dual Serial" USB might survive and allow Debug output?
Only ever used TyCommander (aka TYQT) to pick up the 'second' USB output. With TyComm the primary USB can be turned off to allow the PC to take that IO - and then a second instance will show to be enabled to view debug output.
There is at least one example there for that shows the naming details - seems to be TRIPLE
1718697593378.png

usage is just like 'Serial." only:
Code: 
  while ( SerialUSB1.available() ) {
    int iCH = SerialUSB1.read();

//
    SerialUSB1.print( (char)iCH );
 
In the early days of Teensy 3.0 and 3.1, we regularly heard people say Teensy had lost their program after power cycling. Of course that makes no sense, as the program gets stored in non-volatile flash memory.

After many mysterious reports, we finally realized these programs were using motion sensor chips and Arduino libraries which had been tested on Arduino Uno and similar boards, where the bootloader runs for a second or more before allowing the main program to run. Teensy boots up quickly and does not run the bootloader before your program.

Turns out those motion sensors take time initialize. Not long, like 100-200ms. But the user's program would have started the library which initializes the chip... while it's still busy booting up. Because all the other Arduino boards have delayed start, none of the libraries handle the situation where the motion sensor isn't ready yet. When we asked people to add LED blinks, the blinking would confirm their program ran. Those programs all had one thing in common... they depended on the motion sensor as their primary input and gave no useful output if the sensor wasn't working. From what they could observe, it was as if Teensy worked perfectly when they uploaded their code, but then failed after power cycle.

Eventually we added a 300ms delay in the default startup code. It "fixed" all the motion sensor projects seeming to lose their code after power cycle!

I'm telling this story because you wrote:

markkimball said:
Just to make things even stranger, I was able to re-program and operate the Teensy multiple times with no problems -- until I unplugged it and plugged it back in. Then it went back to a no-boot condition.
Click to expand...

When you get different behavior after uploading than after power cycle, keep in mind your just-uploaded code see already initialized and running hardware. But after a power cycle, it sees uninitialized hardware.
 
Some of the strangeness you're seeing might also be from Linux. Unlike Windows and MacOS which strictly enforce only 1 program being allowed to open the same serial port, Linux allows multiple programs to open the same port. But Linux doesn't handle that situation gracefully. Usually both programs can send, but any incoming serial data gets partially delivered to each program.

There also seems to be a bug on Linux where sometimes a zombie teensy_monitor or teensy_serialmon process can linger. You might run "top" in a terminal to watch for this.
 
I found the problem. It is due to a programming issue of my own making. I was having some different problems so I decided to make a pared-down program that just represented the problematic portion, and failed to copy two very important statements into my setup() routine -- a pinMode() followed by digitalWrite() to force the pin HIGH. The output on that pin is connected to the TFT's RESET pin (!). On a cold boot apparently the floating pin stayed low, so the board always was in its reset mode. As a result the screen stayed blank, making me think the board wasn't booting. Adding those two commands resolved the issue. I'm not sure why the board might eventually start working OK, maybe the weather or my state of mind had something to do with it.....

Red face here. But I owe the responders to my thread an explanation rather than silence and an unresolved issue. Thank you all for your time!
 
You must log in or register to reply here.
Back
Top