serial.print won't print + general debugging issues

Status
Not open for further replies.

gony

Well-known member
hi all
i'm working on a project with teensy 3.6 , code is not good i think , cause i'm not getting any output.

Code:
// PTA (12 13) = [3 4] // ready signal and XS2
// PTB (0 1 2 3) = [16 17 19 18] // For address bits
// PTC (0 1 2 3 4 5 6 7 8 9 10 11) = [15 22 23 9 10 13 11 12 35 36 37 38] // For digital inputs from NI cards
// PTD (0 1 2 3 4 5 6 7 ) = [2 14 7 8 6 20 21 5] // For digital output to marker
// PTE (25) = [34] // for digital output to reward

byte inputPins[] = {3, 4, 16, 17, 19, 18, 15, 22, 23, 9, 10, 13, 11, 12, 35, 36, 37, 38};
byte outputPIns[] = {2, 14, 7, 8, 6, 20, 21, 5, 34};

IntervalTimer myTimerOne;


void reward(void) {
  if (!digitalReadFast(3)  && ((GPIOB_PDIR & 0xF) == 4)){// Received command
    digitalWriteFast(34, HIGH);//reward
    delayMicroseconds(GPIOC_PDIR); //delay time is the reward giving time
    digitalWriteFast(34, LOW); //stop giving reward
  }
}



void setup() {
  pinMode(34,OUTPUT);
  for (int pinnum = 0; pinnum < 18; pinnum++) {
    //    pinMode(inputPins[pinnum], INPUT_PULLUP);
    pinMode(inputPins[pinnum], INPUT);
  }
  for (int pinnum = 0; pinnum < 9; pinnum++) {
    pinMode(outputPIns[pinnum], OUTPUT);
  }
  myTimerOne.priority(0);
  myTimerOne.begin(reward,1);
  myTimerOne.priority(0);
}

void loop() {
  
}

maybe someone can track a simple problem with the code?

anyway , i want to understand what goes wrong and for that i want to print certain things ( for checking ) so i write Serial.begin(9600) in the setup and then the print command but nothing shows in the monitor . i tried all three COM ports none did the job. i plugged everything out and tried to write simple code
Code:
void setup() {
  Serial.begin(9600);

}

void loop() {
   Serial.print("test");
}
also nothing shows up on the monitor for all ports . made sure the usb type is set to serial. made sure baud rate is 9600 in serial begin and in the monitor . my software is up to date and also the monitor did work in the past when i worked on some tutorials.
what can be the cause ?

one more thing ,
is there a better way to debug ? i mean like when i use matlab i have an option to use breakpoints or even step by step progression to see where the error is happening?

thanks a million!
 
This addresses Teensy 'Serial' which is out the USB port to the computer. Under Tools the Sketch must be compiled with 'USB Type: Serial' and the programming cable plugged in and a Serial Monitor opened on the port where the Teensy is connected. If compiled and uploaded the Tools Port should show 'Com# (Teensy)' that when selected will allow the Serial Monitor to collect and display the Teensy output.

Given that - the edited code below should wait for the Serial Monitor to connect to the USB port - say Hi and then proceed to loop().

With no delay as above any Teensy will quickly overflow the receiver's input and processing ability.

Hope this helps ....

Code:
void setup() {
  Serial.begin(9600);
  while ( !Serial ) ;
  Serial.print("Hello World!");

}

void loop() {
   Serial.print("test");
   delay( 500 );
}
 
i copied your code and now its printing !
but still in the main code its not printing .maybe you can look at the more significant code i wrote and see whats wrong with it ?

Code:
// PTA (12 13) = [3 4] // ready signal and XS2
// PTB (0 1 2 3) = [16 17 19 18] // For address bits
// PTC (0 1 2 3 4 5 6 7 8 9 10 11) = [15 22 23 9 10 13 11 12 35 36 37 38] // For digital inputs from NI cards
// PTD (0 1 2 3 4 5 6 7 ) = [2 14 7 8 6 20 21 5] // For digital output to marker
// PTE (25) = [34] // for digital output to reward

byte inputPins[] = {3, 4, 16, 17, 19, 18, 15, 22, 23, 9, 10, 13, 11, 12, 35, 36, 37, 38};
byte outputPIns[] = {2, 14, 7, 8, 6, 20, 21, 5, 34};

IntervalTimer myTimerOne;


void reward(void) {
  Serial.print("test");
  if (!digitalReadFast(3)  && ((GPIOB_PDIR & 0xF) == 4)){// Received command
    digitalWriteFast(34, HIGH);//reward
    delayMicroseconds(GPIOC_PDIR); //delay time is the reward giving time
    digitalWriteFast(34, LOW); //stop giving reward
  }
}



void setup() {
  Serial.begin(9600);
  pinMode(34,OUTPUT);
  for (int pinnum = 0; pinnum < 18; pinnum++) {
    //    pinMode(inputPins[pinnum], INPUT_PULLUP);
    pinMode(inputPins[pinnum], INPUT);
  }
  for (int pinnum = 0; pinnum < 9; pinnum++) {
    pinMode(outputPIns[pinnum], OUTPUT);
  }
  myTimerOne.priority(0);
  myTimerOne.begin(reward,1);
  myTimerOne.priority(0);
}

void loop() {
  
}

as you can see above , i added the Serial.begin command in the setup and than Serial.print command in the beginning of the function called reward (wanted to see if it even gets to initiate the reward function) but than i had a message "Error while setting serial port parameters: 9,600 N 8 1" and the monitor was shifting between online\offline .

is it a problem that the setup function is not first in line ? and about breakpoints , i read that there is no such option in arduino but i couldn't understand the alternatives .
 
Last edited:
Only the second sample had Serial.print() - one was added I see now.

Start with a sample use of IntervalTimer from examples or here: https://www.pjrc.com/teensy/td_timing_IntervalTimer.html

That should work and then with proper modification should get to working. I see 1 microsecond as a problem for having anything print a million times a second: myTimer.begin(function, microseconds);

Make the 'myTimerOne.begin(reward,1);' a bit more conservative to start with a print: myTimerOne.begin(reward,1000000);, and ideally there should not be a print in there at all with reference to the linked page. Just increment a counter and once a second have loop() print it perhaps to know it is running at faster speeds to debug.
 
ok that was a great tip , the problem was the 1 microsecond interval.

now i have another question . i'm using the command Serial.print(GBIOB_PDIR) and the output i receive is the value 13 . that's not what i'm expecting . i initiated as input pins : B0 - 16 , B1 - 17 , B2 - 19 , B3 - 18 . i know for sure (using oscilloscope) that the only HIGH pin is B2 - 19 , so i expect the command Serial.print(GBIOB_PDIR) to print the value 4 ! what am i missing?
 
perhaps I miss it too - didn't check the schematic - try INPUT_PULLDOWN to make sure they are not floating? Tie the inputs to known output and cycle outputs programmatically and see if results are as expected? Read them individually as well to match to the port read? Only using 3V3 right for the T_3.6?
 
1. I'm using only standard devices nothing special , so i assume its the right voltage . ( no external voltage applied accept for the i/o pulses)
2. i'll try the PULLDOWN thing , just making sure . you mean i set the pinmode() to INPUT_PULLDOWN instead if INPUT ?
3. Tie the inputs to known output and cycle outputs programmatically and see if results are as expected? Read them individually as well to match to the port read? - not sure what you mean by that ....


*update*
INPUT_PULLDOWN gave the result of just 0 . the monitor prints 0.
now only pin B1 - 17 is giving a good reading , but when i manually turn the others (B0 B2 B3) HIGH , the monitor would still read 0 . the only solution i can think of is that the schematic is wrong and pins 16 , 18 , 19 are not of port B , but that would be absurd .

further testing show same weird behaviour for port C when i try the command Serial.print(GPIOC_PDIR) -
pins C4 - 10 , C5 - 13 , C11 - 38 are giving good reads (meaning print : 16 , 32 , 2048) but the other pins are just reading LOW even though i see HIGH pulse with the oscilloscope . i'm still using the PULLDOWN btw.

please anyone can figure this out ?
 
Last edited:
OK, I modified your sketch a little (using INPUT_PULLDOWN and printing GPIOB_PDIR in HEX every second) and used a jumper from 3v3, to pin 16, then 17, then 18, then 19, and GPIOB_PDIR value changed as expected. (as defragster notes, make sure you are NOT using 5v to test pins) Maybe a photo of your setup would help. Are T3.6 pins soldered?

Code:
// PTA (12 13) = [3 4] // ready signal and XS2
// PTB (0 1 2 3) = [16 17 19 18] // For address bits
// PTC (0 1 2 3 4 5 6 7 8 9 10 11) = [15 22 23 9 10 13 11 12 35 36 37 38] // For digital inputs from NI cards
// PTD (0 1 2 3 4 5 6 7 ) = [2 14 7 8 6 20 21 5] // For digital output to marker
// PTE (25) = [34] // for digital output to reward

byte inputPins[] = {3, 4, 16, 17, 19, 18, 15, 22, 23, 9, 10, 13, 11, 12, 35, 36, 37, 38};
byte outputPIns[] = {2, 14, 7, 8, 6, 20, 21, 5, 34};

IntervalTimer myTimerOne;


void reward(void) {
  Serial.println("test");
  Serial.println(GPIOB_PDIR,HEX);
  if (!digitalReadFast(3)  && ((GPIOB_PDIR & 0xF) == 4)){// Received command
    digitalWriteFast(34, HIGH);//reward
    delayMicroseconds(GPIOC_PDIR); //delay time is the reward giving time
    digitalWriteFast(34, LOW); //stop giving reward
  }
}



void setup() {
  Serial.begin(9600); while(!Serial);
  pinMode(34,OUTPUT);
  for (int pinnum = 0; pinnum < 18; pinnum++) {
        pinMode(inputPins[pinnum], INPUT_PULLDOWN);
    //pinMode(inputPins[pinnum], INPUT);
  }
  for (int pinnum = 0; pinnum < 9; pinnum++) {
    pinMode(outputPIns[pinnum], OUTPUT);
  }
  myTimerOne.priority(0);
  myTimerOne.begin(reward,1000000);
  myTimerOne.priority(0);
}

void loop() {
  
}

i see HIGH pulse with the oscilloscope
if you are "pulsing" the pin HIGH, then the value in GPIOB_PDIR will only momentarily be 1, so your print might not see it.
 
Last edited:
Maybe try a longer interval than 1 microsecond, especially at top priority which blocks everything else! (like the USB interrupt)
already changed that

if you are "pulsing" the pin HIGH, then the value in GPIOB_PDIR will only momentarily be 1, so your print might not see it.
its not a momentary pulse . the machine im synching is in test mode so i choose whatever pins i want to be HIGH and they are constantly HIGH
 
not sure i understand what you did .
you used jumper wire to connect which 3v3 ? from where to where exactly ?

https://photos.app.goo.gl/pbU55YDr10N5p0Ue2

https://photos.app.goo.gl/ds1tu2modDUh7gOZ2


OK, the photo shows you have NOT soldered your header pins to the T3.6. You MUST solder the header pins.

I was jumpering from teensy 3.6 3v3 pin to each of 16,17,18,19 (testing each pin one at a time)

if your test equipment is on a separate (3v3) power supply, then you need a common ground between the T3.6 and your test equipment. (GND on T3.6 needs a jumper to GND on your test equipment. In the photo, it doesn't appear that there is a jumper to any of the T3.6 GND pins). And one more time, don't feed 5v to your T3.6 pins.
 
Last edited:
ok , so i jumpewire the GND pin of the teensy to the general GND .
and i'll solder the pins ASAP .
about not feeding 5v to the T3.6 pins , i said i don't have any external voltage . do you mean that the oscilloscope applies voltage ? i asked around and people told me it should not be a problem , what do you say?
 
ok , so i jumpewire the GND pin of the teensy to the general GND .
and i'll solder the pins ASAP .
about not feeding 5v to the T3.6 pins , i said i don't have any external voltage . do you mean that the oscilloscope applies voltage ? i asked around and people told me it should not be a problem , what do you say?

Note, you can order T3.6 with header pins already soldered from PJRC.

What is the voltage coming from your test equipment to the T3.6 pins? or what voltage does your scope read when measuring a HIGH from one of your test equipment jumpers? (if your test equipment is feeding 5v into the T3.6 pins, the T3.6 may be damaged. The T3.6 pins want 3.3v. )
 
i'm not sure what is the test equipment , but if you mean the inputs that the teensy receives ,they are 5v pulses. is it damaging the teensy?
 
i'm not sure what is the test equipment , but if you mean the inputs that the teensy receives ,they are 5v pulses. is it damaging the teensy?

Yes, it is likely the 5v has damaged your T3.6 -- but since things weren't soldered, maybe (some of) the pins survived. You would need level-shifters to bring the 5v down to 3.3v, or order a T3.5 with header pins soldered. The T3.5 and T3.2 are 5v tolerant.

https://www.pjrc.com/store/teensy35_pins.html
 
Last edited:
Do not connect 5V signals to any pins on Teensy 3.6.

At least the good news here is, without the pins soldered, use of 5V probably didn't actually make it to the pin. :)
 
is there a chance that the pins weren't damaged ?
i didn't solder them yet , but as i mentioned some did respond to the input and printed HIGH result . does it mean for certain they are fried?
is there a way to check that?
 
If you have any CLIP type adapters that will let you put 3.3V on a pin to test them one by one you can see. Or perhaps write a sketch to set all to INPUT_PULLDOWN - then show when any pin reads 1 - then with a wire 1 by one touch with a 3.3V signal. Be careful where these wires touch! Perhaps reverse the test with INPUT_PULLUP then touch a GND wire to each and print when ZERO. This might save you soldering - or just solder and hope all is well - if you trashed it then ... lesson Learned and you got to practice soldering.

Don't try this at home ( or work ) - I discovered I was feeding 5V to a T_3.6 on 4 pins the other week before I realized the pots were powered by 5V - somehow they survived. I wondered why the last part of the pots as they turned was full scale, I wrongly assumed it was a resolution mismatch - then I realized and wired to 3V3 and they still worked and went 0 to full scale properly.
 
is there a chance that the pins weren't damaged ?

Yes, odds are good your hardware may have survived.

The first step it to check that you can still program the LED blink code. If that works, then solder the pins. Then try uploading the LED blink with the pin number changed to the pins which might have been damaged. Connect a LED+resistor, or just use a voltmeter. This involves many steps, but they are easy and you can do this to discover if your board and all its pins still work.
 
I have a hacked up version of blink I use to test IO pins. It starts off blinking pin 13. You can then enter a pin number in serial port to start blinking that pin instead. If that pin is not pin 13 it switches pin 13 to be an input pin.

So I then jumper that pin over to pin 13 and 13 should blink when I have connected the correct IO pin...

Nothing fancy:
Code:
int current_pin = 13;
int next_pin_number = 0;
void setup() {
    // Blink any pin.  Note: I put pin 13 as input to see if we can
  // jumper to it to see if we can find the pin...
  while (!Serial && millis() < 5000);
  Serial.begin(115200);
  delay (250);
  Serial.println("Find Pin by blinking");
  Serial.println("Enter pin number to blink"); 
  pinMode(13, OUTPUT);
}

void loop() {
  // put your main code here, to run repeatedly:
  if (Serial.available()) {
    int ch;
    while ((ch = Serial.read()) != -1) {
      if ((ch >='0') && (ch <= '9')) {
        next_pin_number = next_pin_number * 10 + (ch-'0');
      } else {
        if (next_pin_number != 0) {
          digitalWrite(current_pin, LOW); // turn the previous pin to low...
          current_pin = next_pin_number;
          pinMode(current_pin, OUTPUT);
          if (current_pin != 13)
            pinMode(13, INPUT);
          digitalWrite(current_pin, HIGH);
          next_pin_number = 0;  // setup to enter next pin
          Serial.printf("Now Blinking pin %d\n\r", current_pin);
        }
      }
    }
    
  } else {
    digitalWrite(current_pin, !digitalRead(current_pin));
    delay(250);
  }
  

}
 
Same problem here

this code doesn't print:
Code:
#include <mag3110_c.h>
#include <Wire.h>

magMain myMag;

void setup() {
Serial.begin(9600);
delay(100);
Serial.println("Test");

}

void loop() {
 
  // put your main code here, to run repeatedly:

}

But this does:

Code:
#include <mag3110_c.h>
#include <Wire.h>

magMain myMag;

void setup() {
Serial.begin(9600);

}

void loop() {
 
Serial.println("Test");
delay(10);
}

I have never had a problem with this teensy (3.6) i used it all the time. I tried the same code with a new one and had the same issue. Blink program works great, if i connect a sensor it also prints the values, but inside the setup brackets its
 
Thank you, while(!Serial); worked, its really weird that this happened, any idea the reason behind it?
 
any idea the reason behind it?

On older boards like Arduino Uno, where there's a dedicated USB-serial chip which does not reboot, your PC sees the same USB device throughout the upload and reboot process. But on native USB boards like Teensy, and most of Arduino's newer products, the USB port is inside the chip which reboots. So your PC sees it as if you had quickly unplugged the USB cable after uploading, and then you quickly plugged the cable back in with the freshly programmed board.

When Teensy boots up, the startup code turns on the USB port. It waits 25 ms before turning on USB (which helps with badly made USB hubs), then another 275 ms before running C++ constructors and then setup(). This 300 ms delay is not about USB, but moreso focused on chips like motion sensors which take a brief time to start up. Almost all Arduino libraries for those chips fail if they're run too soon, so we have this 300 ms startup delay is about compatibility with a large ecosystem of poorly designed libraries, not USB.

Most PC operating systems spend more than 275 ms in USB "enumeration", which is a complex process where your PC tries to discover what type of USB device you've just plugged in. So your setup() code is running while your PC is still trying to figure out which new USB device you've just connected. Linux, Mac and Windows 10 are fairly quick, but rarely complete within 275 ms. Windows 7 can be particularly slow, sometimes taking up to 2 seconds.

Teensy has no control over how long your PC's operating system takes to complete the USB enumeration process and load its drivers. But Teensy can tell you whether the PC's drivers appear to be listening. That's what the "Serial" as a boolean test does. So the "while (!Serial) ;" code is basically waiting for your PC to finish detecting Teensy and loading its drivers. If you do Serial.print() before your PC has its drivers loading and listening for data, whatever you send is lost. It may seem weird, but it's really just a simple matter that Teensy boots up quickly and your code is running before your PC has loaded its drivers and is able to receive data.
 
Status
Not open for further replies.
Back
Top