Arduino MEGA2560 serial port working, can't program through USB

[Staffan321]

Hello,

I have come across a very odd problem - or so it seems.

A while ago I bought two Arduino MEGA2560 on ebay. CH340 USB/serial interface.

One of the units works as expected and can be programmed through USB.
The other one - well. Serial port is working (at least at 115200 bps) - can send and receive characters using a simple sketch.
When connecting a terminal, the arduino resets as expected so also reset is working. I have also verified this on an oscilloscope. When trying to program the board using USB, I see the same kind of reset signal on both the working and not working board (measured at the reset switch - DC block cap from CH340 is working).

Programming the unit is however impossible using the USB port. I get the "avrdude: stk500v2_ReceiveMessage(): timeout".
Have trired to press reset manually with no result.

Programming the board using an AVR ISP mkII works however perfectly well.

Using AtmelStudio I have copied Flash, EEPROM, Fuses and lock bits from the working board to the one that isn't - still same result, can't program using the USB.

Any suggestions?

Regards,
  Staffan

[coromonadalix]

try avrdude with avrdudess

[Staffan321]

Tried the GUI to read EEPROM from non-working Mega, but same fail.
Reading flash and EEPROM from the working one was no problem.

Regards,
 Staffan

[madires]

Missing bootloader?

[Staffan321]

No, the bootloader - or something - is definitely there. It communicates, but in a strange way.

Addition:

I read the FLASH from the working Mega and wrote to the non-working Mega using avrdudess and an AVR ISP mkII. Finally, read the flash from the updated, non-working, Mega. Both 256 kiB files compare with no differences. So, the non-working Mega should have exactly the same flash content as the working one.

Still get the problem with the non-working Mega.

The odd thing is that it appears to be a communication problem from the Mega. Each communication sequence (according to the STK500v2 format) should start with 0x1B (dec 27), but the non-working Mega sends 0x19 for some reason. This probably makes avrdude disregarding the reply.
Looking at the rest of the first (and only) message, it says "AVRISP_2" so I would expect to find this string within the dumped Flash, but I don't find it?

Anyone familiar with the bootloader for Mega?

The dumped flash looks like this where (I believe) the bootloader area begins:

0003e000: 0d94 89f1 0d94 b2f1 0d94 b2f1 0d94 b2f1  ................
0003e010: 0d94 b2f1 0d94 b2f1 0d94 b2f1 0d94 b2f1  ................
0003e020: 0d94 b2f1 0d94 b2f1 0d94 b2f1 0d94 b2f1  ................
0003e030: 0d94 b2f1 0d94 b2f1 0d94 b2f1 0d94 b2f1  ................
0003e040: 0d94 b2f1 0d94 b2f1 0d94 b2f1 0d94 b2f1  ................
0003e050: 0d94 b2f1 0d94 b2f1 0d94 b2f1 0d94 b2f1  ................
0003e060: 0d94 b2f1 0d94 b2f1 0d94 b2f1 0d94 b2f1  ................
0003e070: 0d94 b2f1 0d94 b2f1 0d94 b2f1 0d94 b2f1  ................
0003e080: 0d94 b2f1 0d94 b2f1 0d94 b2f1 0d94 b2f1  ................
0003e090: 0d94 b2f1 0d94 b2f1 0d94 b2f1 0d94 b2f1  ................
0003e0a0: 0d94 b2f1 0d94 b2f1 0d94 b2f1 0d94 b2f1  ................
0003e0b0: 0d94 b2f1 0d94 b2f1 0d94 b2f1 0d94 b2f1  ................
0003e0c0: 0d94 b2f1 0d94 b2f1 0d94 b2f1 0d94 b2f1  ................
0003e0d0: 0d94 b2f1 0d94 b2f1 0d94 b2f1 0d94 b2f1  ................
0003e0e0: 0d94 b2f1 4154 6d65 6761 3235 3630 0041  ....ATmega2560.A
0003e0f0: 7264 7569 6e6f 2065 7870 6c6f 7265 7220  rduino explorer
0003e100: 7374 6b35 3030 5632 2062 7920 4d4c 5300  stk500V2 by MLS.
0003e110: 426f 6f74 6c6f 6164 6572 3e00 4875 683f  Bootloader>.Huh?
0003e120: 0043 6f6d 7069 6c65 6420 6f6e 203d 2000  .Compiled on = .
0003e130: 4350 5520 5479 7065 2020 2020 3d20 005f  CPU Type    = ._
0003e140: 5f41 5652 5f41 5243 485f 5f3d 2000 4156  _AVR_ARCH__= .AV
0003e150: 5220 4c69 6243 2056 6572 3d20 0047 4343  R LibC Ver= .GCC
0003e160: 2056 6572 7369 6f6e 203d 2000 4350 5520   Version = .CPU
0003e170: 4944 2020 2020 2020 3d20 004c 6f77 2066  ID      = .Low f
0003e180: 7573 6520 2020 203d 2000 4869 6768 2066  use    = .High f
0003e190: 7573 6520 2020 3d20 0045 7874 2066 7573  use   = .Ext fus
0003e1a0: 6520 2020 203d 2000 4c6f 636b 2066 7573  e    = .Lock fus
0003e1b0: 6520 2020 3d20 004d 6172 2020 3720 3230  e   = .Mar  7 20
0003e1c0: 3133 0031 2e36 2e38 0034 2e33 2e35 0056  13.1.6.8.4.3.5.V
0003e1d0: 2320 2020 4144 4452 2020 206f 7020 636f  #   ADDR   op co
0003e1e0: 6465 2020 2020 2069 6e73 7472 7563 7469  de     instructi
0003e1f0: 6f6e 2061 6464 7220 2020 496e 7465 7272  on addr   Interr
0003e200: 7570 7400 6e6f 2076 6563 746f 7200 726a  upt.no vector.rj
0003e210: 6d70 2020 006a 6d70 2000 5768 6174 2070  mp  .jmp .What p
0003e220: 6f72 743a 0050 6f72 7420 6e6f 7420 7375  ort:.Port not su
0003e230: 7070 6f72 7465 6400 4d75 7374 2062 6520  pported.Must be
0003e240: 6120 6c65 7474 6572 0020 0057 7269 7474  a letter. .Writt
0003e250: 696e 6720 4545 0052 6561 6469 6e67 2045  ing EE.Reading E
0003e260: 4500 4545 2065 7272 2063 6e74 3d00 504f  E.EE err cnt=.PO
0003e270: 5254 0030 3d5a 6572 6f20 6164 6472 003f  RT.0=Zero addr.?
0003e280: 3d43 5055 2073 7461 7473 0040 3d45 4550  =CPU stats.@=EEP
0003e290: 524f 4d20 7465 7374 0042 3d42 6c69 6e6b  ROM test.B=Blink
0003e2a0: 204c 4544 0045 3d44 756d 7020 4545 5052   LED.E=Dump EEPR
0003e2b0: 4f4d 0046 3d44 756d 7020 464c 4153 4800  OM.F=Dump FLASH.
0003e2c0: 483d 4865 6c70 004c 3d4c 6973 7420 492f  H=Help.L=List I/
0003e2d0: 4f20 506f 7274 7300 513d 5175 6974 0052  O Ports.Q=Quit.R
0003e2e0: 3d44 756d 7020 5241 4d00 563d 7368 6f77  =Dump RAM.V=show
0003e2f0: 2069 6e74 6572 7275 7074 2056 6563 746f   interrupt Vecto
0003e300: 7273 0059 3d50 6f72 7420 626c 696e 6b00  rs.Y=Port blink.

Regards,
 Staffan

[madires]

Strange characters are usually a sign of a mismatched bps rate.

[RoGeorge]

I would try using the good one to upload a bootloader into the non working one.
https://duckduckgo.com/?q=mega2560+upload+bootloader&ia=web

If it still doesn't work after uploading a new bootloader, then maybe it's something wrong with the CH340, or some other hardware problem.

[drvtech]

Could it be a faulty crystal giving you an inaccurate baud rate? How about either checking the frequency using your scope or, as you seem to be able to use Avrdude, writing a short program that outputs 0x55 or 0xAA continuously and looking at the pulse width on the scope.

[Staffan321]

JHello,

Strange characters are usually a sign of a mismatched bps rate.

Could it be a faulty crystal giving you an inaccurate baud rate? How about either checking the frequency using your scope or, as you seem to be able to use Avrdude, writing a short program that outputs 0x55 or 0xAA continuously and looking at the pulse width on the scope.

I dumped the communication with a logic analyzer (Hantek) and it is clear that the 0x19 is really correct. Where there should be two 1s, there is just a single. Also, regular communication is fine - running a script with serial communication works well (uploaded via AVR ISP mkII).

I would try using the good one to upload a bootloader into the non working one.
https://duckduckgo.com/?q=mega2560+upload+bootloader&ia=web

Yes, this was something I tried early. Copying the complete content (FLASH. EEPROM and fuses) from the good one to the bad one. Still not working.

One very odd thing is that during start of communication, the Mega2560 is supposed to send the string "AVRISP_2", and indeed it does. However, when inspecting the binary file from the downloaded FLASH, there is no such string to be found??? I guess I'm missing something, but very unclear what...

If it still doesn't work after uploading a new bootloader, then maybe it's something wrong with the CH340, or some other hardware problem.

Since I see the problem clearly on the TX0 pin of the Mega2560, there doesn't seem to be a problem with the CH340 or even the MCU - it just sends the wrong character.

I can probably live with having to upload code to this very Mega2560 via an AVR ISP mkII, but I would like to understand what is wrong.

Regards,
  Staffan

[RoGeorge]

I would try using the good one to upload a bootloader into the non working one.
https://duckduckgo.com/?q=mega2560+upload+bootloader&ia=web

Yes, this was something I tried early. Copying the complete content (FLASH. EEPROM and fuses) from the good one to the bad one. Still not working.

I'm not sure if by copying the flash of a MEGA2560, the bootloader region is included or not.

I vaguely remember some flash regions that are not casually overwritten, but I didn't double check with the docs.  It's faster to upload a new bootloader and see if it all comes to normal, then to search the docs to see what exactly is copied and what not.

[Staffan321]

Hello,

I'm not sure if by copying the flash of a MEGA2560, the bootloader region is included or not.

I have burnt bootloader via AVR ISP mkII both using Arduino IDE and Sloeber (Eclipse), but no success. Where would the bootloader sit if not in the FLASH?


Regards,
  Staffan

[RoGeorge]

The bootloader is in the flash, too, just that it is sited in a certain area.  Some address ranges from flash are dedicated for a bootloader, and may have extra write protection mechanisms, or not visible at all as normal flash (normal as in destined for the user's code).  This depends on the MCU, and I remember many years ago reading about something like a bootloader area in ATmega type MCU's.

I've just checked, and there are indeed distinct areas in the flash memory, destined for boot and for user code.  See page 20 of 435 in the ATmega2560 datasheet:  https://ww1.microchip.com/downloads/en/devicedoc/atmel-2549-8-bit-avr-microcontroller-atmega640-1280-1281-2560-2561_datasheet.pdf

Flash Program memory space is divided into two sections,
Boot Program section and Application Program section.

Since with the new bootloader still does the same, it seems I was wrong suspecting that to be the cause of malfunction in your board, sorry.

[madires]

Are the fuse bits set the same for both MEGA2560s?

[drvtech]

Are these truly identical mega2650 clones? (Board rev, silkscreen, solder resist etc) Do they have genuine chips with identical (and genuine) manufacturer's markings?

[coromonadalix]

https://support.arduino.cc/hc/en-us/articles/4841602539164-Burn-the-bootloader-on-UNO-Mega-and-classic-Nano-using-another-Arduino

if this doenst work,  the mega  has a problem  in the bootloader range ??


or this one

fuses setting etc ??

https://www.instructables.com/ATMEGA2560-Standalone-Using-Arduino-UNO/

https://petervanhoyweghen.wordpress.com/2015/12/02/the-usbasp-and-atmega2560-mystery/

https://docs.arduino.cc/built-in-examples/arduino-isp/ArduinoISP

[Staffan321]

Hello,

Thanks to all for comments!

Are these truly identical mega2650 clones? (Board rev, silkscreen, solder resist etc) Do they have genuine chips with identical (and genuine) manufacturer's markings?

Yes, they do look very similar and were bought at the same time. It really doesn't seem to be any problem with the hardware (ATmega2560 possibly excluded).

if this doenst work,  the mega  has a problem  in the bootloader range ??


or this one

fuses setting etc ??

It could be. Again, the only reply from the bad Mega is correct in all places _except_ for the first character. I'm fairly certain I get all flash including boot loader area since I cover up to 0x3FFFF (0x1FFFF for word size) when copying. The fuses are the same on both boards.

The bad board really behaves well except for that first character. Looking at the bootloader code (stk500boot.c):

Code: [Select]

case CMD_SIGN_ON:
msgLength = 11;
msgBuffer[1] = STATUS_CMD_OK;
msgBuffer[2] = 8;
msgBuffer[3] = 'A';
msgBuffer[4] = 'V';
msgBuffer[5] = 'R';
msgBuffer[6] = 'I';
msgBuffer[7] = 'S';
msgBuffer[8] = 'P';
msgBuffer[9] = '_';
msgBuffer[10] = '2';
break;

Code: [Select]

/*
* Now send answer message back
*/
sendchar(MESSAGE_START);
checksum = MESSAGE_START^0;

sendchar(seqNum);
checksum ^= seqNum;

c = ((msgLength>>8)&0xFF);
sendchar(c);
checksum ^= c;

c = msgLength&0x00FF;
sendchar(c);
checksum ^= c;

sendchar(TOKEN);
checksum ^= TOKEN;

p = msgBuffer;
while ( msgLength )
{
c = *p++;
sendchar(c);
checksum ^=c;
msgLength--;
}
sendchar(checksum);
seqNum++;

from command.h (included from stk500boot.c):

Code: [Select]

#define MESSAGE_START                       0x1B        //= ESC = 27 decimal
#define TOKEN                               0x0E

Beats me why the board sends 0x19...
Regards,
  Staffan

[RoGeorge]

There was something not very OK about how the RESET signal for the MCU was formed, and for example how you must add a 100uF in parallel to the reset when using another Arduino as a programmer (or else won't program successfully).  This makes me think that maybe the different answer of the two boards is caused by reset-related timings.

I would check the DTR signal and the C7 value between the two boards, at the working vs non working board, to see if there is something different with the RESET while trying to upload a sketch by USB.  Check the other reset related parts, too, the C1 and D3, jumpers, etc.

https://www.arduino.cc/en/uploads/Main/arduino-mega2560_R3-schematic.pdf


Also, I'm not sure if the Reset stops the local oscillator of the ATmega, if it does, maybe the non working board has a lazier oscillator that starts slower.  I would check if there is a significant difference in how fast the local oscillator starts.  If you do that, don't probe the quartz directly with the oscilloscope or with the LA.  The parasitic capacitance of a probe is too big, which will make the start time very different than it really is.  Either route the clock signal to a digital output, and measure the timing between the reset and the DO, or use a field probe if you happen to have one (field probes are non-contact probes).


Another thing to check (in general) when inexplicable errors occur:  make sure you have enough bypass filtering caps for the supply lines, and stable supply voltages.  PC2, C4, C5, C6, C8, C11, C13 and other alike bypass capacitors that I might have missed.

If the power supply lines are not well decoupled and stable, very weird things may happen, including all answer is OK except some Nth bit/byte, always the same one.

[Staffan321]

Hi,

I was leaning toward bad decoupling or the infamous problem with the reset signal so I checked the board early on. Maybe missed something so perhaps an idea to check again.

What still puzzles me is that reading the TX port from the Mega board (=ATmega PE1) I just get this single bit (0x1B becomes 0x19) wrong in the whole sequence.

Regards,
  Staffan

[RoGeorge]

Have you looked with an oscilloscope, too, or with an LA only?  When looking with an oscilloscope, is the failing Tx signal clean enough (or relatively the same dirty as the working board)?

[Staffan321]

I started off with an oscilloscope and noticed bits differing in the beginning of the message. With logic analyzer I realized it was only one bit.

is the failing Tx signal clean enough (or relatively the same dirty as the working board)?

The signals did indeed look very similar.

Regards,
   Staffan

[RoGeorge]

I see you found the sources for that 1B byte.  What will happen when 1B is changed in the sources with something else?

I would make a few tries, with different values instead of 1B, both odd and even values, to see if the error persist, and if it is always the same (a 1->0 for the last bit only).  This won't solve the problem, of course.

Next thing, I would try placing the answer text containing the 1B at a different address in flash, for example insert something that is not optimized out at compile time, or force the address by compile directives, so to align the reply text with 1B somewhere else in flash (I don't know the structure of the bootloader, so don't know which method is more feasible, if any).  The idea is, maybe only that bit in the flash is defective, and it reads 19 during execution.

The last one will disseminate if the error is happening during sending, or if 19 really was loaded into the Tx buffer.

Maybe make it send the entire reply text twice (from sources), to see if it only happen at a certain moment in time relative to reset.  If the second transmission has the 1B correctly, maybe it's something wrong with the supply, if not, maybe it's a defective bit in flash.  Not 100% sure, but what else to do.

[Staffan321]

Yes, good point.

I'm away from the hardware now, but will try to compile bootloader and see if I can get the new version into the Mega.

Regards,
  Staffan