[solved] active serial0 device hangs boot on 2560 - stk500v2 patch/bootloader

update Turns out it is 'problem' with bootloader, i have had a fix created and submitted to arduino project https://github.com/arduino/Arduino/issues/2101 if anyone is interested in compiled bootloader with this fix, let me know

edit changed title, and added this comment to reflect changes * since OP found out it happens on all my mega based boards but not my 328 ones. * believe this is due to 328 bootloader having MAX_ERROR_COUNT parameter but 2560 not * opened ticket https://github.com/arduino/Arduino/issues/1974 * what do you think ? can it be added ?

im finding if i have a transmitting device hooked up to serial 0 it is preventing the arduino from booting... im guessing this is because it is expecting to get a new sketch ? (but is instead just getting the signal from a generic serial device)

does this sound feasible, and any suggestions to get around it ?

as if i plug in the device after boot, it is fine, but i need it always connected, also the device starts transmitting straight away. (once it gets power)

It sounds sort of feasible but I would have thought that Arduino would only expect a new sketch when it was specificallyt told it was about to get one.

I assume the reason why it needs to be always connected is because the transmitting device is powered from Arduino.

I have to bite my tongue as I say this, but I guess a work around is to use software serial, thereby enabling you to get the transmitter off D0. Software serial has it's limitations but they might not be such a problem if you only have one-way traffic.

thanks for your reply, software serial is not an option.

i believe it is excpecting a sketch as that is what it does when it is reset by the ftdi (or in this case the power supply)

and yes power for serial device comes from arduino

what im thinking is to make a circuit that an arduino pin switches the tx line on after a delay of about 3 seconds, which is enough, ive found.

haydent:
thanks for your reply, software serial is not an option.
i believe it is excpecting a sketch as that is what it does when it is reset by the ftdi (or in this case the power supply)
what im thinking is to make a circuit that an arduino pin switches the tx line on after a delay of about 3 seconds, which is enough, ive found.

I won’t ask why software serial is not an option, and I don’t believe Arduino expects a sketch on on reset. I don’t know what an FTDI is but, in that event, what does Arduino do when no sketch arrives - which is usually the case?

That aside, I can’t see a software solution using a delay in Arduino. A 3 sec delay in connecting the Tx is not the same as a three sec delay introduced on reset. If you are short of pins for software serial, a Mega might be the solution, as it has four hardware serial ports - along with a lot of other pins.

thanks again for your input, but im already on a mega and all ports used. if arduino doesnt think its getting a sketch it just boots up like normal. ftdi is chip between usb and arduino connection

haydent: im already on a mega and all ports used.

software serial is not an option.

Beats me.... Maybe it's time to disconnect everything except the alleged offender, and make sure that is where the problem really lies, and then try another device on D0.

tried that, 3 different serial devices, all same problem.

Hmmm... As I said, it beats me,and it's time for dinner and the news. It's probably something silly, and easily fixed. This can't be the first Arduino to be connected to a serial stream.

time for dinner and the news

agreed :sleeping:

haydent: does this sound feasible, and any suggestions to get around it ?

Yes, it sounds completely feasible. If the bootloader starts receiving serial data then you'd expect it to keep reading it and trying to make sense of it.

One easy way to resolve the problem would be to get rid of the bootloader. Having done that, you'd need to upload sketches using ICSP in future, which is no problem if you have another Arduino to use as a programmer. You can also use ICSP to reinstall the bootloader if you change your mind in future.

thanks for you help, just realised its only happening on my custom mega based board, and not on my standard mega duino. i might investigate what bootloader they each run...

found this:

For the following half-second or so, the bootloader is running on the Mega2560. While it is programmed to ignore malformed data (i.e. anything besides an upload of new code), it will intercept the first few bytes of data sent to the board after a connection is opened. If a sketch running on the board receives one-time configuration or other data when it first starts, make sure that the software with which it communicates waits a second after opening the connection and before sending this data.

http://arduino.cc/en/Main/arduinoBoardMega2560

the bold bit is the interesting bit, it appears they already accounted for my problem, so i must investigate further...

http://www.arduino.cc/en/Guide/Troubleshooting#sketchstart

Why doesn't my sketch start when I power up or reset the Arduino board?

Most likely because you are sending serial data to the board when it firsts turns on. During the first few seconds, the bootloader (a program pre-burned onto the chip on the board) listens for the computer to send it a new sketch to be uploaded to the board. After a few seconds without communication, the bootloader will time out and start the sketch that's already on the board. If you continue to send data to the bootloader, it will never time out and your sketch will never start. You'll either need to find a way to stop serial data from arriving for the first few seconds when the board powers (e.g. by enabling the chip that sends the data from within your setup() function) or burn your sketch onto the board with an external programmer, replacing the bootloader.

updated title and added note to OP to reflect research update

fix created and added to OP