Odd programming behavior on a DUE derived board
i've been working 2 weeks off , on bringing new sam3x8e board based loosely on due. smaller 50x50mm form factor , incorporates ksz8081rna phy , ethernet connection among other things.
by way of history have 40 years of electronics design experience processors, programmable logic, rf , high voltage pulsed power. isn't first rodeo arm processor , using sam-ba boot monitor.
other normal rev 0 problems missing pull-ups , pull-downs things appeared going smoothly. dropped atmel usb interface , erase , reset jiggery pokery in favor of straight ftdi ft230 interface on debug port , kept native usb port.
both arduino ide , bossa interface , sam-ba software able find processor , interact on both native , debug serial port. sam-ba examine, erase , program flash memory , flash utility loaded , ran in ram space processor operating.
i did hardware erase , tried loading arduino blink program using native usb port, had tested on true due board , nothing. ide said programmed, verified, set gpnvm bit boot flash , reset cpu no blinky led. hardware reset applied - no blinky. ok..... fire sam-ba , around.
first of all, sam-ba shouldn't have been able open port if had been set boot flash, had still booting sam-ba rom. bossa lied.
the blink program in flash. verifies against compiled .bin file arduino ide. try manually setting boot flash0 , boot flash gpnvm bits. hardware reset - nothing. close sam-ba, unplug usb port , plug in , launch sam-ba again - doesn't find port @ least hasn't booted rom, still no activity.
i spend week off , on chasing including session of pin-by-pin comparison between real due , our board nothing relevant found. searched , at91sam forums, removed phy chip in case causing problem. no change.
i load atmel design studio , prepare go @ through jtag port. new segger firmware promptly bricks our j-link clone no jtag until our "real expensive" j-link gets here that's rant time.
fast forward today. same behavior. program there, no booting rom no program execution. i've tried mapping io different pins, etc. today reason while in sam-ba executed "set gpnvm0 protection bit " command in sam-ba , started blinking.........
ok....i tried repeating several sequences , combinations. nothing runs until set protection bit. arduino loads code flash correctly still boots sam-ba rom after that. if fire sam-ba after , set gpnvm code protect bit , nothing else runs , blinking led.
has else had similar experience bringing own board? under impression code protect keep code being read out. can't explain why difference between real due , board when using native usb port. i'm interested in ideas , i'm happy post code , schematics if think help. i've @ least got way move forward.
allen
ceo
celeritous
by way of history have 40 years of electronics design experience processors, programmable logic, rf , high voltage pulsed power. isn't first rodeo arm processor , using sam-ba boot monitor.
other normal rev 0 problems missing pull-ups , pull-downs things appeared going smoothly. dropped atmel usb interface , erase , reset jiggery pokery in favor of straight ftdi ft230 interface on debug port , kept native usb port.
both arduino ide , bossa interface , sam-ba software able find processor , interact on both native , debug serial port. sam-ba examine, erase , program flash memory , flash utility loaded , ran in ram space processor operating.
i did hardware erase , tried loading arduino blink program using native usb port, had tested on true due board , nothing. ide said programmed, verified, set gpnvm bit boot flash , reset cpu no blinky led. hardware reset applied - no blinky. ok..... fire sam-ba , around.
first of all, sam-ba shouldn't have been able open port if had been set boot flash, had still booting sam-ba rom. bossa lied.
the blink program in flash. verifies against compiled .bin file arduino ide. try manually setting boot flash0 , boot flash gpnvm bits. hardware reset - nothing. close sam-ba, unplug usb port , plug in , launch sam-ba again - doesn't find port @ least hasn't booted rom, still no activity.
i spend week off , on chasing including session of pin-by-pin comparison between real due , our board nothing relevant found. searched , at91sam forums, removed phy chip in case causing problem. no change.
i load atmel design studio , prepare go @ through jtag port. new segger firmware promptly bricks our j-link clone no jtag until our "real expensive" j-link gets here that's rant time.
fast forward today. same behavior. program there, no booting rom no program execution. i've tried mapping io different pins, etc. today reason while in sam-ba executed "set gpnvm0 protection bit " command in sam-ba , started blinking.........
ok....i tried repeating several sequences , combinations. nothing runs until set protection bit. arduino loads code flash correctly still boots sam-ba rom after that. if fire sam-ba after , set gpnvm code protect bit , nothing else runs , blinking led.
has else had similar experience bringing own board? under impression code protect keep code being read out. can't explain why difference between real due , board when using native usb port. i'm interested in ideas , i'm happy post code , schematics if think help. i've @ least got way move forward.
allen
ceo
celeritous
a few people have reported odd behaviour custom boards , officials dues. i've seen funny behaviour due clones.
i powered own design, coresam3x, , had no trouble programming ide via native usb port. coresam3x pretty stripped down version of due. experience more embedded software electronics design pleasantly surprised worked first time!
possibly 1 problem area reset line, may sensitive rise time wrt power rails.
ps. segger clone died well, using official segger edu version.
i powered own design, coresam3x, , had no trouble programming ide via native usb port. coresam3x pretty stripped down version of due. experience more embedded software electronics design pleasantly surprised worked first time!
possibly 1 problem area reset line, may sensitive rise time wrt power rails.
ps. segger clone died well, using official segger edu version.
Arduino Forum > Products > Arduino Due (Moderator: fabioc84) > Odd programming behavior on a DUE derived board
arduino
Comments
Post a Comment