Go Down

Topic: What do I need to do to resolve this Serial Print issue? (Read 1 time) previous topic - next topic

Chrisbee

Hi everyone...

Using a Due and IDE 1.8.3. all I get is gibberish when I use Serial Monitor.  But it was working last time I used this feature.

I have googled, and see others have had issues with USB interphase and gibberish.

Anyway. Everything else appears to work fine, I can upload new sketches. If I query the board via "Get Board Info " I get an expected results.  EG
BN: Arduino Due (Programming Port)
VID: 2341
PID: 003D
SN: 6403636313935190D021

I have tried different versions of IDE (1.8.2 and 1.6.13) still no change. I have tried different baud rates, still no good.


I have upload a bit of code for my Mega, Serial print works fine on this board, same IDE same PC and USB and same baud rates.

On the DUE (code below in void Spectrum() )
Serial.print("myColour = ");  returns backward version of  "??????="
Serial.println(myColour); returns a letter and a number  EG "RT2" ECT.

Was unable to copy and paste the Serial monitor screen. But have included a screen shot.

I have added some code below, the whole code is to big to add here, but this should be enough so YOU can see. happy to add anything else that you may require to help me here.

Code: [Select]

#define BAM_RESOLUTION 4
const  int Size_CW = ((1 << BAM_RESOLUTION) - 1) * 6;
int myColour = 0;// General purpose variable.

void setup() {

  Serial.begin(115200);

  //*** Set up SPI - Using SPI Library.
  SPI.begin();//start up the SPI library
  SPI.setBitOrder(MSBFIRST);//Most Significant Bit First
  SPI.setDataMode(SPI_MODE0);// Mode 0 Rising edge of data, keep clock low
  SPI.setClockDivider(4);//Run the data in at 21MHz
  //Set up the Outputs for Latching and Blanking pins on the shift registers .
  pinMode (6, OUTPUT); // Sets PIOC bit 24 as output, blank_pin.
  pinMode (7, OUTPUT); // Sets PIOC bit 23 as output, latch_pin.

  //*** Here layer pins are set as outputs
  pinMode(23, OUTPUT);// Layer 1
  pinMode(25, OUTPUT);
  pinMode(27, OUTPUT);
  pinMode(29, OUTPUT);
  pinMode(31, OUTPUT);
  pinMode(33, OUTPUT);
  pinMode(35, OUTPUT);
  pinMode(37, OUTPUT);
  pinMode(39, OUTPUT);
  pinMode(41, OUTPUT);
  pinMode(43, OUTPUT);
  pinMode(45, OUTPUT);// Layer 12

  FillColourWheel();//Fill colour wheel with array of colour - Call Colour [0 - Size_CW] [0=R,1=G,2=B] or GetColour[colour#]
  //**** Calculate the time required to upload the shift registers. Used to set min On time in Backend. ***********
  unsigned long InterruptUpdateRunTime = micros();
  TC3_Handler();                //Call Cube Update code to see how long an update takes.
  MinInterruptTime =  (micros() - InterruptUpdateRunTime ); //Time taken to upload the shift registers once.

  //****Start the Interrupts *******
  startTimer(TC1, 0, TC3_IRQn, 1000); //TC1 channel 0, the IRQ for that channel and the desired frequency
 
}//***end setup***

void loop() {
 
  Spectrum();

}

void Spectrum() {
  for (myColour = 0; myColour < Size_CW; myColour++) {
    GetColour(myColour);
    Serial.print("myColour = ");//<------------------------here
    Serial.println(myColour);//<------------------------here

    for (byte y = 0; y < Size_Y; y++) {
      for (byte x = 0; x < Size_X; x++) {
        for (byte z = 0; z < Size_Z; z++) {
          LED(y, x, z, myRed, myGreen, myBlue);

        }
      }
    } delay(100);
  }
  CleanCube();
}

//********** Get Colour and check it is within tolerance. ********************
void GetColour(int colour) {// Standard colours from colour wheel

  while (colour < 0) {              //If "colour" is a negitive value
    colour += Size_CW;
  }
  while (colour >= Size_CW) {       //If "colour" is greater than Size of Colour Wheel.
    colour -= Size_CW;
  }
  myRed = Colour[colour][0];
  myGreen = Colour[colour][1];
  myBlue = Colour[colour][2];
}

//Clean Cube *********************************************
void CleanCube() {
  memset(red, 0, (Size_Cube / 8)* BAM_RESOLUTION * sizeof(byte));
  memset(green, 0, (Size_Cube / 8)* BAM_RESOLUTION * sizeof(byte));
  memset(blue, 0, (Size_Cube / 8)* BAM_RESOLUTION * sizeof(byte));

}// *****************************************************

Where should I be looking?

pert

Try this code:
Code: [Select]
void setup() {
  Serial.begin(115200);
}

void loop() {
  Serial.println("hello");
  delay(1000);
}

Does it also produce gibberish?

Chrisbee


Robin2

Yes same backward ?????.
Are you sure the new program has actually been uploaded?

Maybe it is still running the old code?

Add some code that flashes an LED in a pattern that you can easily recognize to confirm that the new program has been loaded.

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

Chrisbee

Are you sure the new program has actually been uploaded?


Quite sure. The number of backwards ?? = the number of letters in the word. I have tried a few different word sizes and variables. This Due is not easy to get to, can't even see it.

Robin2

Maybe you should click Report to Moderator and ask for this Thread to be moved to the DUE section?

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

Chrisbee

Maybe you should click Report to Moderator and ask for this Thread to be moved to the DUE section?

...R
Done.

Chrisbee

Still playing around with this issue. I have removed the IDE completely and re -installed. No change.


When I added the Due board to the IDE, I did get a newer version 1.6.11. I noticed with this version, the compile time is much less.

If I use a baud rate of 19200, I can almost read the text "myColour" looks like "m?Colo?r"  and at this baud, the variable is reporting back ok.  I have tried other speeds too, with varying results.

Robin2

If I use a baud rate of 19200, I can almost read the text "myColour" looks like "m?Colo?r"  and at this baud, the variable is reporting back ok.  I have tried other speeds too, with varying results.
That looks like the signal is getting screwed up somewhere. Is it better at 9600 baud?

Have you tried using a different USB cable?
You say the DUE is inaccessible - would that have anything to do with it? Take it out of its hidey-hole and put it on your desk and see what happens.

Does this happen only with your DUE - in other words do other Arduino boards work OK

Have you tried sending the data to another Arduino by connecting the Tx and Rx pins to Rx and Tx (and GND to GND). I would expect an Arduino Mega to have no problem working at 500,000 baud.


...R
Two or three hours spent thinking and reading documentation solves most programming problems.

ard_newbie

The only explanation I found concerns the Atmega 16U2 firmware. If you have an old DUE board from 2013 , the Atmega16U2 firmware was buged in the first versions of the DUE (2013).

See this thread, reply #25 for a fix:
http://forum.arduino.cc/index.php?topic=134847.15

Edit: A supply voltage too low can corrupt your Atmega 16U2 EEPROM --> Same fix

Chrisbee

That looks like the signal is getting screwed up somewhere. Is it better at 9600 baud?

Have you tried using a different USB cable?
You say the DUE is inaccessible - would that have anything to do with it? Take it out of its hidey-hole and put it on your desk and see what happens.

Does this happen only with your DUE - in other words do other Arduino boards work OK

Have you tried sending the data to another Arduino by connecting the Tx and Rx pins to Rx and Tx (and GND to GND). I would expect an Arduino Mega to have no problem working at 500,000 baud.


...R
Robin, yes it is somewhat better if I use a slower baud rate, EG19600 return something much closer to what I expected to see. EG myColour looks like myCol??r at the slower rate.

as for the location of the DUE, it is a planned job to retrieve. I'm about to go OS so I have decided to leave it as is till I return. BUT it has always worked while in its location. This issue is new, the due has worked fine with Serial.print till now or at least before I updated the IDE to 1.8.3.

And yes, I have tried different cables and USB ports.I have also connected a MEGA and it works fine with the same IDE, Cables PC ETC.

The only explanation I found concerns the Atmega 16U2 firmware. If you have an old DUE board from 2013 , the Atmega16U2 firmware was buged in the first versions of the DUE (2013).

See this thread, reply #25 for a fix:
http://forum.arduino.cc/index.php?topic=134847.15
I will look into this later today, but I have the latest version of IDE V 1.8.3 and the latest DUE board manager V 1.6.11.  Serial.print was working.

I'm thinking I have a fault on the board. everything seem fine but for Serial.print  I have a new DUE ordered.


Thanks guys for taking an interest in my issue here, appreciated.
I'm about to make a few changes to my main code and would like the debug facility available before I do that. Chris.

pert

I will look into this later today, but I have the latest version of IDE V 1.8.3 and the latest DUE board manager V 1.6.11.
That has no relation to the firmware version on the ATmega16U2. As to whether that firmware version might be related to your problem, I have no clue. If you buy a clone it's anyone's guess what firmware the cloners ship their boards with.

Chrisbee

#12
Sep 24, 2017, 03:29 pm Last Edit: Sep 24, 2017, 03:34 pm by Chrisbee Reason: Opps, wrong quote....Fixed.
Well the new Due has arrived and works just fine in relation to Serial.print.
Next :-

That has no relation to the firmware version on the ATmega16U2. As to whether that firmware version might be related to your problem, I have no clue. If you buy a clone it's anyone's guess what firmware the cloners ship their boards with.

Go Up