Arduino 2 - serial port disappears

J

jblaze

Well-known member
I upgraded my hardware to Mac OSX Sonoma 14.2.1 and running an M3 unit
Arduino: 2.2.1
Teensy via boards manager: 1.58.1

Old unit was still an MacIntel machine (10.15.7):
Arduino: 1.8.13
Teensyduino: 1.53

When I upload my perfectly running program, the serial port disappears and the program does not start. Using other USB ports or unplug/plug back does not help-
Memory Usage on Teensy 4.0:
FLASH: code:256324, data:186672, headers:8584 free for files:1580036
RAM1: variables:229504, code:249416, padding:12728 free for local variables:32640
RAM2: variables:513760 free for malloc/new:10528
Click to expand...

I can only reflash the unit when I press the programming button on the Teensy. Compiling exactly the same on the old unit, everything runs fine.

Any other stuff I can add to help troubleshooting?
 
Two things to check:

1) What "USB Type:" have you chosen from the Tools menu ??

1706018613213.png


2) Have you tried to include CrashReport() support in the setup() function as follows:

Code: 
while(!Serial) ;
if (CrashReport)
   Serial.print(CrashReport);

Note that with the Crash Report monitor written this way (specifically, the while(!Serial);), it will wait forever if the Serial Monitor is not connected, so this added code should be commented out and/or removed after you've identified & resolved the cause of your crash.

Mark J Culross
KD5RXT
 
jblaze said:
I upgraded my hardware to Mac OSX Sonoma 14.2.1 and running an M3 unit
Arduino: 2.2.1
Teensy via boards manager: 1.58.1

Old unit was still an MacIntel machine (10.15.7):
Arduino: 1.8.13
Teensyduino: 1.53

When I upload my perfectly running program, the serial port disappears and the program does not start. Using other USB ports or unplug/plug back does not help-


I can only reflash the unit when I press the programming button on the Teensy. Compiling exactly the same on the old unit, everything runs fine.

Any other stuff I can add to help troubleshooting?
Click to expand...
Please show your code.
Enclose it between CODE tags using the </> button.
 
jblaze said:
I upgraded my hardware to Mac OSX Sonoma 14.2.1 and running an M3 unit
Arduino: 2.2.1
Teensy via boards manager: 1.58.1
Click to expand...
Using the board manager try manually updating to 0.59.5. That's the current test version for the upcoming 1.59, 1.58 had some bugs that could cause crashes on startup like you're seeing.
 
@kd5rxt-mark

Serial is set to "serial".

I added "Crash report", but i do not get any serial port from the device. As if the microcontroller doesnt run the whole program proberly.
 
jmarsh said:
Using the board manager try manually updating to 0.59.5. That's the current test version, 1.58 had some bugs that could cause crashes on startup like you're seeing.
Click to expand...

I downgraded the Teensy support to 0.59.5 but the problem persists

When I flash an empty sketch, the Teensys startsup ok and comes up with the serial port.
 
jblaze said:
Small sketches work fine.
Click to expand...
That would suggest that the problem is with your software.

You could start adding software back until the problem re-appears
OR
Remove (or isolate) software from your original code until the problem goes away--the last removed would likely be the problem area.
 
Since Teensy 4.0 was released in 2019 and Teensy 4.1 in 2020, many people have written large programs without the serial port disappearing. Large programs do indeed work, if written well.

We've also seen numerous times on this forum, and many times helped fix programs of all sizes that went wrong in ways similar to what you're describing. Whether those problems were the same as your program, I can't say (and please consider any help any of us tries to give here when we can't see your code is blind guessing) but I can tell you programs which crash early (while Windows is still reading USB info to detect the freshly connected hardware) will almost always act as you've described. Based on a lot of experience over the last 4 years, I can say with confidence it's not a matter of program size. Well, other than large programs simply have more code and if any particular line does something wrong like dereference of a null pointer, you'll get this sort of issue.
 
If we can't see your code, only pretty generic advice is possible. BriComp's suggestion to remove or isolate portions of your program is usually the best way. You could also try adding a substantial delay (several seconds) at the beginning of your program to allow time for the USB code to respond to Windows. If your program defines C++ classes, remember that C++ constructors run before setup(). You can use the startup hooks to run a delay early, before constructors are executed.

More generic advice... a problem we commonly see on this forum is C++ constructors which call other classes. Generally speaking, your constructor should only access its own class if you use any static instances (which are the norm with Arduino-style programming). The potential problem with using any other class is that other class's constructor might not have run yet. For this reason, Arduino libraries generally follow a convention where the construtor only initializes the class's variable and a begin() function provides the functionality to actually start up the hardware and do anything "real". In Teensyduino 1.57 we had special design in the Serial, Serail1, Serial2, Wire, SPI classes to allow them to be safely used from other class construtors. That broke with the new toolchain in 1.58. It is fixed in 1.59 beta. So if you are using 1.58 and you have any custom classes in your program, look at your constructor code for any use of those common classes. If so, install the latest beta or downgrade to 1.57 if you don't want to run beta releases (but now's a pretty good time since we're in the final stages before a 1.59 stable release).

Well, that's a lot of words that amount to 100% blind guessing, but maybe it helps anyway? If there's one take-away point I can make, it's that we know large programs definitely do work. Many people have sucessfully created quite large programs over the last few years.
 
Thanks for the input guys. Pauls hint " I can tell you programs which crash early" pushed me into the right direction.

I was able to cut down the problem to this code:

Code: 
extern "C" void startup_early_hook(void) {
  pinMode(2,OUTPUT);
  digitalWrite(2,LOW);
  pinMode(0,INPUT);
  pinMode(1,INPUT);
}

It's important drive drive these pins as early as possible. Anything I can change?
 
Using startup_early_hook() this way is risky. It runs too early, before the GPIO configuration registers are set up, before static variables are written with their initial values, etc. Even if it happens to work today, you could expect problems with future software versions.

If you call functions, rather than hard-code the raw hardware register writing (which is carefully designed for uninitialized hardware), you really should use startup_middle_hook().
 
Would this be correct for the "startup_early_hook"?

Code: 
  GPIO9_GDIR |= (1<<4);  // pinMode(2,OUTPUT);
  GPIO9_DR_SET &= ~0xF7; // digitalWrite(2,LOW);


  GPIO6_GDIR |= (1<<2);  // pinMode(1, OUTPUT);
  GPIO6_DR_SET = (1<<2); // digitalWrite(1, HIGH);

  GPIO6_GDIR |= (1<<3);  // pinMode(0, OUTPUT);
  GPIO6_DR_SET = (1<<3); // digitalWrite(0, HIGH);
 
Do I need to initialize the pins in fast mode upfront?


Code: 
IOMUXC_GPR_GPR27 = 0xFFFFFFFF; // Initialize pins

GPIO9_GDIR |= (1<<4);  // pinMode(2,OUTPUT);

  GPIO9_DR_SET &= ~0xF7; // digitalWrite(2,LOW);





  GPIO6_GDIR |= (1<<2);  // pinMode(1, OUTPUT);

  GPIO6_DR_SET = (1<<2); // digitalWrite(1, HIGH);



  GPIO6_GDIR |= (1<<3);  // pinMode(0, OUTPUT);

  GPIO6_DR_SET = (1<<3); // digitalWrite(0, HIGH);
 
You have to set the pin mux (IOMUXC_SW_MUX_CTL_PAD_GPIO_*) and the pin pad configuration (IOMUXC_SW_PAD_CTL_PAD_GPIO_*).
 
You must log in or register to reply here.
Back
Top