Here's a little background. I was using an Arduino MEGA 2560 to control external circuitry via XBee or USB depending on the situation. This was working perfectly as a proof of concept but now I have to have it all on one board. Eventually, this will likely be updated from arduino to some form of a a TI stellaris but for now I have to use the ATmega2560. I layed out a simple board (schematic attached) that has the ATmega2560, an FT232RL USB to UART bridge from sparkfun (USB to UART Bridge - FT232RL - COM-00650 - SparkFun Electronics), an XBee Pro XSC and some other stuff that shouldn't matter for this. I am able to program the board via the ICSP headers from AVR studio as well as by using the upload from programmer option in the arduino ide (version 1.0.1 - also, I am on windows 7 64 bit). The code appears to be functioning properly. I verified this changing the initial state a few times and observing the outputs on the GPIO pins. The problem is, I can not communicate with the board over the USB or XBee, I can only load code via ICSP headers.
I uploaded a simple sketch that initializes Serial (USB) and Serial2 (XBee) with a baud rate of 9600. In the loop, I do a Serial.print('A') from each port. I initially examined the output from the XBee in XCTU. For every time the Serial.print is executed, I am receiving 0x00 0x00 0x00 which shows as ". . ." in the terminal. I initially suspected it was an XBee problem but I am receiving the same thing over USB. I suspect that it may have something to do with the HardwareSerial library but I'm not sure. I would like to think that it's not a hardware problem but I could be wrong. I very well may be the worlds worst programmer, so please keep that in mind and talk to me as if I was a complete idiot (because I am).
Another possibly related problem that I am encountering is with the bootloader. I tried to burn the bootloader from Arduino IDE but it froze. I successfully programmed the hex file to the flash and when I attempt to load a sketch to the custom board via USB, it freezes in the upload phase. I then uploaded the bootloader hex file to the arduino mega board and the same thing happens when I try to upload code to it.
Like I said, I think it's a software issue related to the serial communication functions but I could really use some extra (smarter) insight.
Like I said, I think it's a software issue related to the serial communication functions but I could really use some extra (smarter) insight.
It works on one hardware, but not another, so you think it must be a software problem. I don't follow that logic.
I should be more clear, it USED to work on one hardware. I am not new to PCB design and have extensively reviewed the schematic and layout (so did my friends that work at sparkfun) and we all agree that the board looks okay.
PaulS:
Does it, or does it not, still work on that hardware?
I just tried to upload the code to test it but the Arduino MEGA is now reporting an incorrect device ID so I can't program it. I tried the force option from the Arduino IDE but then I got a verification error and it fails to enter programming mode in AVR studio.
I uploaded this code to the board, and sent the character 'A' over usb via xctu. Sometimes I have to send it a few times before there is a response. But after I send one character, it responds with a single 0x00 in every iteration of the loop rather than with 'A' just once.
char data;
void setup(){
Serial.begin(9600);
}
void loop(){
if (Serial.available() > 0){
data = Serial.read();
Serial.write(data);
Serial.flush();
}
delay(100);
}
AdamPrulhiere:
I uploaded this code to the board, and sent the character 'A' over usb via xctu. Sometimes I have to send it a few times before there is a response. But after I send one character, it responds with a single 0x00 in every iteration of the loop rather than with 'A' just once.
char data;
void setup(){
Serial.begin(9600);
}
void loop(){
if (Serial.available() > 0){
data = Serial.read();
Serial.write(data);
Serial.flush();
}
delay(100);
}
I also tried it with serial.print and serial.println. it is pretty consistently starting to send the bytes back after i send 2 characters to the board. Serial.write and serial.print respond with 1 by of 0x00 in each iteration while serial.println responds with 7 bytes.
Sometimes I have to send it a few times before there is a response.
Why are you only looking for serial data every 100 milliseconds?
If you remove that, you might get a more responsive board. If not, then there is something wrong with your hardware. The only thing wrong with your software is the useless Serial.flush() statement.
If you are using 1.0+, that call simply blocks until all sent data has actually been moved to the output register for sending. Since you are only sending one character every 100 milliseconds, that one character is moved immediately to the output register.
PaulS:
Why are you only looking for serial data every 100 milliseconds?
If you remove that, you might get a more responsive board. If not, then there is something wrong with your hardware. The only thing wrong with your software is the useless Serial.flush() statement.
If you are using 1.0+, that call simply blocks until all sent data has actually been moved to the output register for sending. Since you are only sending one character every 100 milliseconds, that one character is moved immediately to the output register.
Just to slow it down. without the delay it does the same thing only a lot faster. This isn't the actual code I need to run, I'm just trying to get the comm up and running.
When I declare data as an int it sends back a different number of bytes each time. I've seen anywhere between 13 and 22 bytes. I added the serial.flush after I saw the same behavior without it. The schematic is pretty much the same as this board http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Dev/Arduino/Boards/mega_pro-v13.pdf with the addition of the USB to UART bridge which I connected according to the datasheet. And the computer recognizes the UART as a com port. I tried to upload a picture of my schematic but failed. I'm not saying that it's not a hardware issue, but I am an EE grad student and I think that a hardware error (at least schematic/layout) is pretty unlikely. I specialize in RF and antennas so there always is the chance i did something stupid on the digital side but i've had several people look at the schematic and they didnt see anything wrong.
PaulS:
The delay, then, belongs in the if(Serial.available() > 0) block.
If you are seeing serial data being available, after the Serial.read(), with sending only one character, then it is a hardware problem.
Whether that hardware is the board you built or the PC, I do not know. The fact that you can't talk to the Mega concerns me. Is it an official Mega?
Yes it's official. I am in contact with sparkfun about that. I uploaded the bootloader hex file that came with the software download to the flash and ever since then i havent been able to talk it. i'm going to go poke around with a scope to see what's happening on the lines.
I am looking at the TX/RX pins on the scope and they have the correct data (with the xbee connected the data remains high, only the start bit can be seen). but with the xbee off the board i see the proper data on both TX0 and TX2. I know that the correct ASCII is going from the ATmega to the UART. I can also see the correct data go from the UART to the ATmega when i send a byte over USB. however, I am still seeing the same output on my terminal. I have tried replacing the UART and see the same behavior. And i assume that it is wired correctly because the data goes from the PC to the UART to the ATmega intact....not sure what to make of this but I'm gonna say its probably not a software issue.
The baud rate is WAY OFF. I verified the clock was correct and then realized that instead of 9600 as expected, the actual data rate was about 625 bps. I used this to scale the baud rate up to 147456 (serial.begin(147456) and i started seeing the correct characters returning. there were quite a few data errors as would be expected since it was a quick measurement/calculation but what would cause the baud rate to be off by a factor of ~15.36?
Would you care to elaborate a little further on the solution that you found?
I was working on an Uno last weekend with a RF receiver and saw similar patterns of continuously reading 0's. From my experiments, the .available() would always return > 0.
sorry for the late response. like i said, the baud rate was way off. it was a result of programming the board from the arduino IDE. Since i had the same processor as the mega 2560, i selected that from the boards option. the problem is that caused the IDE to expect a 16 MHz clock while i was using a 1 MHz clock. the baud rate that i saw on the oscilloscope was about 16 times slower than it should have been. I unchecked the divide clock by 8 fuse and that resulted in the baud rate only being off by a factor of two. Finally, i put a 16 MHz crystal on and everything seemed to work. the reason i was only seeing 0's transmit is because it saw the (slow baud) start bit not only as the start bit but as the data as well. hope this helps, let me know if you have any questions.