Teensy boot problem

Status
Not open for further replies.

Manu

Well-known member
Hi,

In a project I currently achieve, I found a problem that may be code related.
I have a CAN enhanced module that read 4 TK sensors temperature and send them over the CAN bus. I also have USB connection to allow module configuration per serial commands (this can also be do using specifics CAN frames).

Problem :
- If I have the USB cable attached to a computer, the module won't operate. There is no COM port for teensy in the windows hardware screen. No CAN frame is send
- If I have the USB cable attached to a computer, the module won't operate. Then if I press the program button windows detect the Teensy and program it. At the next boot the module operate as normal (COM is available and CAN frames are send)
- If the cable is unplugged on boot sequence, the module operate. CAN frames are send as normal operation. If I then plug the USB cable in my computer, a COM port is created for teensy and I can access it.

My guess :
The way I initiate Serial COM fail if the teensy is plugged at boot sequence ?

Here is the setup code :
Code:
void setup() {
  Serial.begin (115200);
  Serial.setTimeout(100);
  // Do the other setup tasks
}

Then in Loop I have :
Code:
void loop() {
  if (Serial.available()) // Mode configuration.
  {
    confFromSerialWithCRC();
  }
  // Do the other loop tasks
}

Does anyone can tell me if I have do something the wrong way ?
Thank,
Manu
 
Not sure how much code is excluded - this isn't a working example to begin to understand. The code shown should operate well, unless something not shown it doing something odd. Though I've never done Serial.setTimeout()- or seen it used?

This is like what I typically use - except for the BOLD option line - and if Serial connects within 5 seconds the following print works - if not it is typically lost even if connected later, but it fails harmlessly.
Code:
void setup() {
  Serial.begin(115200);
[B]    delay(1000); // OPTIONAL ADDED delay[/B]
  while (!Serial && millis() < 5000 );
  Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);

  // …
}

The call 'confFromSerialWithCRC();' only executes when USB is actively connected? Something in this - or other setup code if excluded?

The fact that it works after programming suggests a warm start avoids a race condition on some hardware being addressed before it is ready to react/respond properly. If this is the case then the above 'OPTIONAL' code may help as it will add some short delay before getting to that code - though it will be short without that more explicit delay.
 
Thank defragster for this tip :

Code:
while (!Serial && millis() < 5000 );

I'll try it, with a more lower timing (1000 for example).

I use
Code:
Serial.setTimeout(100);
to speed up the teensy CHAR catch on the serial bus. As I only send short commands (1 to 10 chars), I faced slow serial behaviour. I think this is due to teensy buffer big size.

anyway, here is my complete code :

(proprietary code deleted)
 
Last edited by a moderator:
Hum,

Today I use another power supply to power up my circuitry and each boot is fine. So maybe the problem is related to the way I power up the circuitry.
 
Something that may upset the USB port electrically is if your power supply has a markedly different gnd to the USB gnd on the computer - basic check there is to measure the voltage between the teensy USB Gnd and the Computer USB gnd (normally case gnd) when they are not connected to each other. It is possible your USB port is being disabled at the computer end when it detects abnormal voltages present.
 
Interesting - some power supplies have shown startup timing issues on T_3.6 IIRC - but that shouldn't hit with USB power.

Has VUSB<>VIN been cut? Are USB and external power on at the same time - if so then that underside trace should be disconnected. That still leaves GND for current back to PC.

I see this after startCAN - the prior post suggest putting another before that :: delay (500);

Teensy enters setup() with millis at 350 on newer builds of TD - sometime Serial is ready then or shortly after - up to 50 to 150 perhaps if the SerMon program is active on the port.

it would be interesting to know where it is failing - total stoppage or altered execution?

I would use this lib and see where it is going and dying - this will work while USB is connected, which is when you have trouble - this post is the last I uploaded - and posts before and after and examples give an idea of how I'd use it.
 
When you mentioned about different power supply works, again wondering if you have cut the VUSB/VIN line.

Again not sure what Teensy you are using and what power supply. As mentioned, there are a few power supplies that the T3.6 has shown issues with. It has to do with how the voltage ramps up...

Sometimes with issues like, this I try to put in some additional debug stuff. Example at the start of setup(), put in something like:
Code:
pinMode(13, OUTPUT);
for (int i=0; i< 5; i++) {
  digitalWrite(13, HIGH);
  delay(250);
  digitalWrite(13, LOW):
  delay(250);
}
Then see if the LED flashes five times or not... If so you know you at least made it to setup, and maybe not power related. Maybe then move it down farther in setup, and see if you find a place where it no longer works... If the LEDS don't flash, than could be power related issue. Could be global objects with constructors issues...

Again if the LEDS in setup works, then I often do other digital writes and trace with Logic Analyzer and/or setup to use TTL serial port, like Serial1 to output debug information. I then use some TTL to USB converter to connect up that Serial port to PC to watch the debug information.
 
Thank to everyone for interests with this problem.

This project use a custom board from my own and haven't teensy board on it due to space constraints. So yes, it may be hardware related. This is why I ask about my code to see if there are bigus on it. As it look like that there is no bug in it AND that changing power supply changer the behaviour of this custom board, it may be hardware related.

Previously, I read about someone who face the same problem and found a power supply fault that alter the boot up of MK20. This is I think my problem too. I should use a TI switcher on my board (LMZM26300V3) for the final batch, but at this time I use a bad Chinese converter (switcher to). I think my problem is related to it.

Anyway, I'll keep you in touch about the way I solve this problem.

Thank,
Manu
 
Status
Not open for further replies.
Back
Top