Teesny 3.6 - Serial communication via USB is out unless using SD.begin()

Status
Not open for further replies.
A

AxelB

New member
Hello, I tumbled upon an awkward issue last night : my Teensy 3.6 won't communicate by the USB cable (with my windows 10 laptop) unless I include the SD library & call SD.begin(<anything>)

For instance, this script does not print anything :
Code: 
void setup() {
  Serial.begin(9600);
  Serial.println("Test");
}
void loop() {}

While this one does print "Test" :
Code: 
#include <SD.h>
void setup() {
  SD.begin();
  Serial.begin(9600);
  Serial.println("Test");

}
void loop() {}

I have been told that the RX/TX pins seemed to be mysteriously pulled up/down by a dark force and that the SD library somehow deblocked it...

I had been using this card for a while without any issue regarding the serial communication (though I had trouble using the internal SD card). The problem appeared when I first tried to read the register SDHC_IRQSTAT, which contains the status data of the internal SD card (I wanted to checj if it was detected). Now, each of my programs suffers the same issue, wether they use the SD card/SD libraries or not...

I'm looking for a short-term solution in priority because this teensy card is meant to be used in an important test next week, but I would love to understand this problem in order to definitively avoid it...
Thank you in advance for any advice !
 
The usual problem:
Teensy is too fast to see Serial.println("Test"); of monitor
insert while(!Serial);
before Serial.begin(9600);
 
Frank B said:
We need a FAQ.
And why doesn't Serial.begin do that automatically.. (with timeout)
Click to expand...

Serial.begin is empty!

re FAQ: Forget about it:
"https://www.pjrc.com/" does not even shows T4.0, so FAQ, WIKI etc is behind the moon, which is easier to reach
 
I know. Would be easy to add it to begin().
There must be a strong reason not to add it (I'd like to know..)

Documentation: Agreed.
 
Frank B said:
We need a FAQ.
And why doesn't Serial.begin do that automatically.. (with timeout)
Click to expand...

Frank B said:
I know. Would be easy to add it to begin().
There must be a strong reason not to add it (I'd like to know..)

Documentation: Agreed.
Click to expand...

Paul did this 'by default' some many versions back at some point - maybe in Beta - it changes default behavior for everyone putting an unexpected delay() in setup().

Perhaps suggesting an added ",timeout" value for a new .begin() would be easy - but not portable.
 
defragster said:
Paul did this 'by default' some many versions back at some point - maybe in Beta - it changes default behavior for everyone putting an unexpected delay() in setup().

Perhaps suggesting an added ",timeout" value for a new .begin() would be easy - but not portable.
Click to expand...

Yup, but the delay is still not long enough.
The timeout can be a fixed value - or a default that can be overriden by your proposal.

I think I had a pullrequest for this, some years ago.
Finally, I closed it.
 
Frank B said:
Yup, but the delay is still not long enough.
The timeout can be a fixed value - or a default that can be overriden by your proposal.

I think I had a pullrequest for this, some years ago.
Finally, I closed it.
Click to expand...

IIRC - In that 'beta' is actually stayed much longer - a second or more - in .begin() until (Serial)

After that it went back to minimal time of the USB to init to be stable with the current short delay - and shorter and USB Init takes even longer as I tried it.
 
Would it be a dilemma to add while (!Serial && millis() - timeout > 1000) inside Serial.begin()? Or if it's part of the arduino API to have it run when the API calls the core configuration? This would solve all the issues of multiple threads of people taking about the same problem i think
 
tonton81 said:
Would it be a dilemma to add while (!Serial && millis() - timeout > 1000) inside Serial.begin()? Or if it's part of the arduino API to have it run when the API calls the core configuration? This would solve all the issues of multiple threads of people taking about the same problem i think
Click to expand...

That was noted in p#7. IIRC - It was tried and is a dramatic change when any sketch is built with the change.

Current CORES calls setup() after "while (millis() < 300) ;" - it used to be longer { 350 to 400ms ? } some many months back. So on entry to setup() time zero is currently 300ms with TD_1.51.
>> while (!Serial && millis() - timeout > 1000+300) // to wait 1 second

Depending on PC and USB and SerMon it can be online at 340 to 550ms based on recall of prior testing done. That leaves time for user to 'do stuff'. And on Teensy the Serial.begin() is not needed and does nothing - if compiled to have Serial … it is started before setup() entry.

Some Arduino hardware had different and some similar behavior based on hardware MCU - Teensy behavior on ARM's is established and consistent ... just needs a brief intro … like anything it can catch people … and results in recurring questions and issues.

Having Serial.begin() without a user timeout - or defaulting to 0 wait - would break/change a lot of existing sketches.
 
Status
Not open for further replies.
Back
Top