I've been working about 2 weeks off and on bringing up a new SAM3X8E board based loosely on the DUE. It is a smaller 50x50mm form factor and incorporates a KSZ8081RNA PHY and Ethernet connection among other things.
By way of history I have about 40 years of electronics design experience with processors, programmable logic, RF and high voltage pulsed power. This isn't my first rodeo with an ARM processor and using the SAM-BA boot monitor.
Other than some normal Rev 0 problems like some missing pull-ups and pull-downs things appeared to be going smoothly. We dropped the Atmel USB interface and its ERASE and RESET jiggery pokery in favor of a straight FTDI FT230 interface on the debug port and also kept the native USB port.
Both the Arduino IDE and its Bossa interface and the SAM-BA software were able to find the processor and interact with it on both the native and debug serial port. With SAM-BA I could examine, erase and program the flash memory and the flash utility loaded and ran in the RAM space so the processor was operating.
I did a hardware erase and tried loading the Arduino blink program using the native USB port, which I had previously tested on a true DUE board and nothing. The IDE said it programmed, verified, set the GPNVM bit to boot from flash and reset the cpu but no blinky LED. Hardware reset applied - no blinky. OK..... fire up SAM-BA and look around.
First of all, SAM-BA shouldn't have been able to open the port if it had really been set to boot from flash, so it had to still be booting from the SAM-BA ROM. Bossa lied.
The blink program is in flash. It verifies against the compiled .bin file from the Arduino IDE. I try manually setting the boot from flash0 and boot from flash GPNVM bits. Hardware reset - nothing. I close SAM-BA, unplug the USB port and plug it back in and launch SAM-BA again - it doesn't find the port so at least it hasn't booted from the ROM, but still no activity.
I spend about a week off and on chasing this including a session of pin-by-pin comparison between the real DUE and our board with nothing relevant found. Searched this and the AT91SAM forums, even removed the PHY chip in case it was causing a problem. No change.
I load Atmel Design Studio and prepare to go look at it through the JTAG port. New Segger firmware promptly bricks our J-Link clone so no JTAG until our "real expensive" J-Link gets here but that's a rant for another time.
Fast forward to today. Same behavior. Program is there, no booting from ROM but no program execution. I've tried mapping IO to different pins, etc. Today for some reason while in SAM-BA I executed the "Set GPNVM0 Protection Bit " command in SAM-BA and it started blinking.........
OK....I tried repeating it with several sequences and combinations. Nothing runs until I set the protection bit. Arduino loads code to flash correctly but it still boots to SAM-BA ROM after that. If I just fire up SAM-BA after that and just set the GPNVM code protect bit and nothing else it runs and I get blinking LED.
Has anybody else had a similar experience with bringing up their own board? I was under the impression the code protect was just to keep the code from being read back out. I can't explain why the difference between the real DUE and this board when using the native USB port. I'm interested in any ideas and I'm happy to post code and schematics if you think it will help. For now I've at least got a way to move forward.
Allen CEO Celeritous