ATmega16U2 in Mega 2560 R3 no com port and flash problem

Hello.
I have the arduino mega 2560 R3.
As I understand, I got it without usb-serial software in atmega16u2, because in windows device manager I had only "ATmega16U2", but no COM ports. I saw checksum 0xFF when start Flip and connect to usb port. I have tried to load file "Arduino-usbserial-atmega16u2-Mega2560-Rev3.hex" by Flip - successfully. Checksum also changed from 0xFF to 0x70** (I don't remember exact value), but after reset I haven't com ports. When I start Flip again, I see that checksum of flash contents again is 0xFF ! Why?

I tried to use dfu-programmer under Windows and Linux. I loaded file "Arduino-usbserial-atmega16u2-Mega2560-Rev3.hex" successfully in both cases, but after reset I haven't com ports. I got flash dump by dfu-programmer to the file "dump.hex". Checksum of this file differ from original "Arduino-usbserial-atmega16u2-Mega2560-Rev3.hex" ! Why?

I also tried to load file "Arduino-usbserial-atmega16u2-Uno-Rev3.hex" - same results.
At this moment I can't work with this arduino from Arduino IDE directly in Windows, because Arduino IDE ask for com port. But in Linux OS I can work in Arduino IDE with /dev/ttyACM0. I loaded "blink" successfully. But I can't use Linux OS every time when I need to load code. Why Arduino IDE on Windows can't work without com port but with ATmega16U2 as IDE on Linux?

How can I fix this problem and get com port in windows?
Thank you in advance.

Compare the two hex files - what's different, if anything? It's informative to know if it's writing anything at all, whether it looks like things didn't get erased, etc.

What's strange though is that it works on linux, which implies that the code has been loaded successfully... Do you know that drivers are installed and working correctly on windows?

DrAzzy:
Compare the two hex files - what’s different, if anything? It’s informative to know if it’s writing anything at all, whether it looks like things didn’t get erased, etc.

I attached 3 files:
Arduino-usbserial-atmega16u2-Mega2560-Rev3.hex - file, what I loaded by dfu-programmer and Flip
dump_loaded.hex - dump flash after successful loading of “Arduino-usbserial-atmega16u2-Mega2560-Rev3.hex”
dump_erased.hex - dump flash after erase command in dfu-programmer

You can see that all 3 files are differ. But, as I understand, the most part of the file is loading successful, exept some last lines.

DrAzzy:
What’s strange though is that it works on linux, which implies that the code has been loaded successfully… Do you know that drivers are installed and working correctly on windows?

Yes, I’m sure that windows haven’t any problems with drivers, because:

  1. There aren’t any new devices after loading hex file;
  2. I tried on 2 different PC with win 7 x86 (fresh install) and win 7 x64
  3. Linux OS haven’t com ports also - only ttyACM0, but there isn’t any ttyUSB

P.S. I work with Arduino Mega2560 (not R3) with integrated CH340 in Windows successfully. I understand, that its require another drivers - it’s only for information.

Arduino-usbserial-atmega16u2-Mega2560-Rev3.zip (4.24 KB)

dump_erased.zip (177 Bytes)

dump_loaded.zip (4.2 KB)

Those hex files look equivalent to me. The dump just made slightly different decisions about how to treat the last few bytes of the flash - they're both equally valid and describe the same data.

DrAzzy:
Those hex files look equivalent to me. The dump just made slightly different decisions about how to treat the last few bytes of the flash - they're both equally valid and describe the same data.

No! Theese files are match before line #251.
Line #251 of the original file begins with "1";
Line #251 of dump_loaded.hex begins with "0".

Lines #251:
0C0FA000AC01BD01CF010895F894FFCF13 - original
100FA000AC01BD01CF010895F894FFCF00034000CC - dump

As I understand, theese line are different at all.

The same situation occurs with lines #252:
100FAC0000034000000440000002080000000000A4 - original
100FB00000044000000208000000000000000000E3 - dump

Other lines also differ.

That's why I said equivilent, not identical. They represent the same data.

The original has

0C0FA000AC01BD01CF010895F894FFCF13

That means we have 12 bytes starting at offset 0FA0

Then
100FAC0000034000000440000002080000000000A4

16 bytes starting at 0FAC (12 bytes after the last one started, ie, right after it)

And those first 4 bytes are 00 03 40 00

The dump puts those 4 bytes onto the end of the first line, making it the normal 16-bytes long, and continues from 0FB0, correctly starting with 000440000002080000000000

And so on.

See:

Thank you for explanation.
So, we can draw a conclusion, that dfu-programmer really writes hexfile's content.
So, why it isn't working?

Maybe problem is content of atmega16u2 eeprom? I saw in Flip, that eeprom checksum is 0xFF also.
Can somebody upload files with outputs of:
dfu-programmer atmega16u2 dump > dump.hex
dfu-programmer atmega16u2 dump-eeprom > dump_eeprom.hex
dfu-programmer atmega16u2 dump-user > dump_user.hex
from atmega16u2 ?

P.S. I try load new code from Linux OS again (by /dev/ttyACM0), but I'm getting "stk500v2_ReceiveMessage(): timeout" now!