Uart1 not sending or receiving data - Atmega2560 custom board

Using Arduino Programming Questions
#1

Hello.

I have 2 Atmega2560 controllers on my custom board which are connected via UART1. Both the controllers have Arduino Mega's bootloader which is downloaded from 'burn bootloader' option into the Arduino IDE.

Programming of both the controllers is done via the ICSP headers.

Now the problem is i'm not being able to communicate via UART1. The other UARTS; UART2, UART3 and UART0 all works fine on both the controllers.

Operation done so far: Contoller1 sends a character via UART1 to Controller2 which is also receiving data at UART1.

Results observed: null character on the Realterm terminal software.

Also tried sending the same thing from controller2 to controller1 on UART1 bridge but the same results.

Tried sending the same character on other UARTS (0,2,3) and it all works fine. Only UART1 of both the controllers which are connected to each other seems to act weird.

Is the bootloader of MegaBoard has to do anything with this problem??
Or is there a hardware problem between the bridge?

Thanks.

#2

Could you have messed up wiring and connected Rx 1 to Rx 1 instead of Tx1 (and Tx 1 to Tx 1 instead of Rx 1)??

#3

No. That's the first thing that i checked. Connections are all proper.

#4

Since it’s a custom board hard to help without design and checking for short circuits and other hardware issues

Nothing else connected on those pins?

#5

No. Nothing else connected.

#6

When idle what is the voltage on the serial1 pins? It should be ~Vcc.

Check with DVM in continuity mode - check that none of the pins are shorted to Vcc, Gnd, eachother, or any other adjacent pin (it can be helpful to clip the leads of the DVM to pins (the kind you use in sewing) or unbent safetypins, so they come to a sharp point. )

Are both Arduino's powered during your tests? They must be - it can actually damage the unpowered arduino if they're not, since you'd be "backpowering" it through the protection diodes on it's RX pin.

#7

Board is working fine except for UART1. So the power pins are properly isolated and not shorted anywhere. Checked continuity on the controller pins itself between the Tx and Rx. Nothing else connected in the path of UART1. Can i try anything on the software end also to exploit more on this issue?

Both the controllers are powered together.

#8

what piece of code do you use to test?

#9

Right now for testing UART1, i'm using simple serial read and write.

Controller 1 -- TX

void setup()
{
   Serial1.begin(19200);
}
void loop()
{
  delay(40);
  Serial1.println("Hello");   // Also tried write() instead of print
}

Controller 2 -- RX

{
   Serial.begin(19200);
   Serial1.begin(19200);
}
void loop()
{
  if (Serial1.available() > 0)
  {
     Serial.println(Serial1.read());
  }
}
#10

the code seems fine indeed…

do you have the possibility to test output to something else than the other proc? (ie route somewhere else the signal - like a FTDI or a scope…)

#11

nrkhara:
Board is working fine except for UART1. So the power pins are properly isolated and not shorted anywhere. Checked continuity on the controller pins itself between the Tx and Rx. Nothing else connected in the path of UART1. Can i try anything on the software end also to exploit more on this issue?

Both the controllers are powered together.

DrAzzy:
When idle what is the voltage on the serial1 pins? It should be ~Vcc.

Check with DVM in continuity mode - check that none of the pins are shorted to Vcc, Gnd, eachother, or any other adjacent pin (it can be helpful to clip the leads of the DVM to pins (the kind you use in sewing) or unbent safetypins, so they come to a sharp point. )

Are both Arduino's powered during your tests? They must be - it can actually damage the unpowered arduino if they're not, since you'd be "backpowering" it through the protection diodes on it's RX pin.

It's not clear if you've tried the other things I mentioned. Check the idle voltage levels on Serial1 (you can upload a sketch that does nothing except do Serial1.begin(19200) to both boards for this) - make sure they're both at Vcc in this case.

Also, did you test that there is no continuity between the two data lines (ie, that they're not shorted to eachother)? Or between TX/RX and Vcc, Gnd, or any other adjacent pin? It's particularly important if you're assembling it yourself (either via drag soldering or reflowing at home); at that pitch, bridged pins can happen easily and are hard to spot. This sort of testing, while it seems silly, solves a large portion of the problems that I have to get out the DVM for.
Also, try setting up those two sketches, and poking the transmitting mega2560's TX pin with the tip of a pin/safety pin, pressing it down. Do the same on the receiving mega2560's RX pin. This is a check for cold solder joints.

Are both boards running at the speed you think they are? If there's an LED that you can control from the code, modify blink to use that pin; make sure it blinks at the expected speed.

Do you have a scope? If so, look at the line that should be carrying data - is it?

There is no reason to suspect a software issue here; the code is dead simple. I cannot think of any debugging at a software level that would be useful here; all evidence points to an as-yet unidentified hardware issue.

#12

Okay. I'll have a look at these points.

#13

DrAzzy:
It's not clear if you've tried the other things I mentioned. Check the idle voltage levels on Serial1 (you can upload a sketch that does nothing except do Serial1.begin(19200) to both boards for this) - make sure they're both at Vcc in this case.

Also, did you test that there is no continuity between the two data lines (ie, that they're not shorted to eachother)? Or between TX/RX and Vcc, Gnd, or any other adjacent pin? It's particularly important if you're assembling it yourself (either via drag soldering or reflowing at home); at that pitch, bridged pins can happen easily and are hard to spot. This sort of testing, while it seems silly, solves a large portion of the problems that I have to get out the DVM for.
Also, try setting up those two sketches, and poking the transmitting mega2560's TX pin with the tip of a pin/safety pin, pressing it down. Do the same on the receiving mega2560's RX pin. This is a check for cold solder joints.

Are both boards running at the speed you think they are? If there's an LED that you can control from the code, modify blink to use that pin; make sure it blinks at the expected speed.

Do you have a scope? If so, look at the line that should be carrying data - is it?

There is no reason to suspect a software issue here; the code is dead simple. I cannot think of any debugging at a software level that would be useful here; all evidence points to an as-yet unidentified hardware issue.

There were some cold solder joints on the controller pins. Did a complete touch up of the connections and voila, everything works perfect now. I wonder how sometimes such little things are the solution for such irritating problems.

Thanks for all the inputs given for debugging on the hardware end. Will use this in future if i face similar problem.

Cheers!!

#14

great ! have fun ! :slight_smile:

#15