DIY Arduino due board can programming but nothing work on SAM3X

HI ALL:

I followed the Arduino due schematic ( arduino-Due-schematic.pdf)to print my own Due Board, currently i think the burn process seems alright, but the IC can't do what i programmed , despite the burn is succeeded, it doesn't seems like the program is burned into the board.

"when it's burning"
the signals from Tx Rx from usb port to Atmel-16U2, the light of outer Tx Rx from 16U2 (16U2 ->pin 10 ,11 ) is glowing correctly, and the waveform burned from 16U2 to Tx Rx of the SAM3X is correct too, and it's shows burn succeed in the end.

I burned Blink program for testing, but when i probe Pin68(Digital 13), the voltage doesn't change.

Again, i burned another program which can deliver the value back constantly into the board, but the signal which should transmit from the output of SAM3X TX to USb port is missing.

I guess it might be an IC failure so I changed a new one but the result is the same.

I'm wondering that if the compile process is succeeded doesn't it means that the 16U2 and SAM3X can communicate with each other.

If there's more information you think it'll be helpful please ask me, thank you.

Due + W5500.pdf (98.9 KB)

1.PNG

2.PNG

There may be some inconsistencies in DUE schematic, e.g.:
https://forum.arduino.cc/index.php?topic=168399.0

i have add my schematic on it , and i think i have the right Y4 crystal for 16 MHZ

Is there any possiable that cuz i use connector for USB-Type -B not USB-MICRO B so that cause Error?

I'm having a similar issue, I'm on my 2nd layout as there was a mistake which made the core run at 3v3 instead of 1.8 via the VddOut regulator in the sam3x. Oddly, that actually worked, it just got rather toasty.
On those boards, I did some modifications so that it would run on 1.8v (including the IO, but still 3v3 for USB), but it was unreliable until I turned the volts on the core up a bit (I did this on a fresh board that had never seen 3v3 on its core). I also changed the X'tal for an oscillator, this seems to work. Other than that, I pretty much followed the Arduino Due circuit minus the slow programming port (Native only).

The new boards are recognised until I program them, windows then sees nothing attached at all! I don't even get the windows beep when I plug it in, but hit erase and sure enough windows beeps and it shows up. I will be playing with the core volts later to see if that springs it into life.

Due circuit minus the slow programming port (Native only).
The new boards are recognised until I program them, windows then sees nothing attached at all! I don't even get the windows beep when I plug it in, but hit erase and sure enough windows beeps and it shows up.

What sketch did you program them with? I mean, this sounds like "expected behavior" for the native USB port, UNLESS your sketch explicitly includes USB code. No USB Code, no USB activity. The autoreset/upload features of the arduino are implemented either by having the 16u2 fiddle with the reset and erase signals, or by having the usb code from the previous sketch recognize the "reset" command... (I think.)

I programmed them with a simple pin toggle. I added pin 92 to variant.cpp which is port B 9
I hadn't spotted that pins 4 and 10 are connected to 2 pins each on the sam3x, hence the 77/87 used in the code below (they are defined in variant.cpp)

void setup() {
 // put your setup code here, to run once:
pinMode(77, OUTPUT);//pin 4
pinMode(87, OUTPUT);//pin 10
pinMode(92, OUTPUT);//pin TST
}

void loop() {
 // put your main code here, to run repeatedly:
 digitalWrite(77, HIGH);
 digitalWrite(87, HIGH);
 digitalWrite(92, HIGH);
 delay(100);
 digitalWrite(77, LOW);
 digitalWrite(87, LOW);
 digitalWrite(92, LOW);
 delay(100);
}

This works fine on a real Due and on the overvolted core version but not on the new 'fixed' boards.
I have yet to turn the core volts up on the new boards, hopefully I will get to try that today.

I have noted that even if the USB isn't used, the PC does still change from "Bossa Programming port" to "Arduino Due" in device manager after programming (on the Due and the overvolted core versions obviously).

GPM2.pdf (201 KB)

The extra I added to variant.cpp just before "// END" in the pin description table

  // 92 - GPM Test Pin
  { PIOB, PIO_PB9, ID_PIOB, PIO_OUTPUT_0, PIO_DEFAULT, PIN_ATTR_DIGITAL, NO_ADC, NO_ADC, NOT_ON_PWM, NOT_ON_TIMER },

I should also mention that I'm using the 144 BGA device (two of them if you happen to download the pdf in my previous post).

Thanks all i found the problem that 16U2 Reset pin unconnect to my main chip ,it been fixed

thanks all again

Frank.

Thanks for the update; I really appreciate having the causes of "odd" behaviors explained, even when (especially when?) my guesses were wrong.