Odd programming behavior on a DUE derived board

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

A few people have reported odd behaviour with custom boards and even some officials Dues. I've also seen some funny behaviour with Due clones.

I recently powered up my own design, CoreSam3x, and had no trouble programming it with IDE via native USB port. CoreSam3x is a pretty stripped down version of a Due. My experience is more with embedded software than electronics design so I was pleasantly surprised it worked first time!

Possibly one problem area is the RESET line, which may be sensitive to rise time wrt to power rails.

PS. My Segger clone died as well, now I am using official Segger EDU version.


Glad to hear your board started up without any problems. I'm probably going to build my Rev2 a little at a time so I can start with a pretty stripped down version before populating the other bells and whistles.

Thanks for the reply. I did some looking at the reset lines and the voltage rails and the LM27342 3.3V switcher is taking several mS to start up. The reset line was going high before the 3.3v rail was stable. Even in that state, once the code protect bit was set it would start code execution on power-up.

In addition to pulling the PHY off I pulled the module off its carrier board which supplies the raw DC power and powered it directly to make sure none of the external connections were affecting it. No change.

Pulling the PHY chip did reveal a couple of shorted lines under the chip (I hate QFN packages) and once I re-installed it I am getting an activity light and Ethernet activity when connected to a router. I also ran some code using the internal RTC library and it works and I was able to see the 32kHz crystal oscillating.

I was originally driving the NRSTB line with the external pushbutton until I read that it also reset the RTC so I did switch over to the NRST as the external reset line but it didn't change the behavior of needing the protection bit set before running.

I'm working on Rev 2 to clean up some other unrelated issues and thinking I may need a reset controller to do a better job of making sure the 3.3 is up and stable before doing a reset.

I did get my "official" J-Link EDU in earlier this week so I'm hoping to try it out during the break when things are quiet and see if I can look into this further. I'll post any results from that exercise.