Go Down

Topic: Arduino due Native port not working (Read 954 times) previous topic - next topic

Tady

Oct 21, 2015, 11:37 pm Last Edit: Oct 22, 2015, 06:19 am by Tady
Hello!

I  got my arduino due a few weeks ago and I gave it a go today. The programming port is working fine.
But I have a big problem with the native port. Windows does not see it. I mean when I connect the usb cable no sound is played on the computer (usb device connected). When I go to the device manager there is nothing new connected... like the port is just for powering.. I tried different usb cables and different usb ports.... I tried the erase and reset buttons.. nothing.
I uploaded the blink sketch  and then I pressed the erase button. The L led stops blinking and stays on forever (the button works).
I have searched the whole forum and i can't find any related problems. So is there anything I can try or is my board defective?

Thank you!

P.S. I'm using Windows 8.1

TheRevva

By the sound of things, you've taken all the right steps to confirm it all, but I've chosen to re-hash it all below so that it's hopefully clearer for the next person reading this thread...  (It took me a while to grasp it all!)
The only thing that springs to mind is to de-power and then re-power the board AFTER you've erased it with the erase button.  (I'm guessing you tried this, but you didn't actually type it).

What I'd suggest is that you upload a simple sketch (through the programming port of course) that makes the native USB port into a simple USB to serial loopback device.  (There's plenty of examples to pick from online).  i.e. It enumerates itself as a simple USB<->serial converter that echos back anything it receives.  This should at least let you know if the hardware is fine.  It's my guess that this is where you'll find 'issues'.  (It's not uncommon for the micro USB connector to be poorly reflowed onto the board.  It COULD even be one of the two 39 ohm resistors that hook through to the full-speed USB pins on the SAM chip.
If you happen to have a 'spare' USB cable that you can 'butcher', check the voltages on the D+ and D- lines.  You _SHOULD_ find one of those two lines pulled up to 3V3 via the internal 1k5 pullup resistor if the 3X8E is properly erased and therefore is booting from SAM-BA in ROM (see below).  Without that pull-up, your host machine (the Wind-Blows Hate thing... LOL) will not KNOW that you've plugged in a USB device and therefore will not give you any noises to signify the enumeration process success / failure.

---
Long winded stuff... Grab a beer AND a coffee before you read this!!!

The PROGRAMMING port is the one that's hooked up to the separate 16U2 processor on the Due.  The 16U2 is basically acting as a glorified USB to Serial converter (with an extra 'feature' when a 1200Baud connection is made through USB which effectively pushes the erase button under software control)
You've already stated that this aspect works fine, so I'll not elaborate much further on this one.

The NATIVE port that is built in to the SAM3X8E processor is, by comparison, a somewhat different animal and I'll try my best to explain it all for any others here.
The SAM3X8E contains a chunk of ROM as well as 2 'banks' of Flash.  There's also a few bits of non volatile memory which are rather vital.  Upon reset, the processor ALWAYS starts executing whatever code resides at address 0x00000000.
This is where the non-volatile memory comes into play because it determines WHAT is actually located at the 0x00000000 boot address.  Taking a look at figure 8-1 on the SAM3X8E datasheet detailing the memory map should help a bit here...
The REAL starting address of the first bank of Flash is actually 0x00080000
The REAL starting address of the second bank of Flash is actually 0x000c0000
The REAL starting address of the ROM is actually 0x00100000
NONE of them natively reside at the 0x00000000 boot address!!!
However...  Depending upon the setting of the non volatile memory, ONE of those three chunks are mapped (aliased) to our boot area at 0x00000000.  When the chip is totally erased, the non volatile bits tell it to remap the ROM to the boot area, and the code that's stored in ROM (which they named SAM-BA).  This ROM code initialises the UART to 115200/8/N/1 and the native USB port.  It then 'polls' waiting for an incoming USB connection OR a received character through the UART.  (This is described in detail within section 22 of the SAM3X8E datasheet).
When you upload a program (aka 'sketch' to use the given Arduino name), the program is uploaded into Flash, and once that's done, it sets the non volatile memory such that it now boots from the freshly uploaded Flash instead of from the original ROM.
If your program (sketch) was uploaded through the programming port, then it came via the 16U2 which uses the UART methodology of the SAM3X8E.  However, if you uploaded it through the native port, then it bypassed the 16U2 altogether.  In order to do this though, the SAM3X8E had to first be ERASED thereby telling it to boot from the internal ROM in order to initialise the USB peripheral and run SAM-BA.
Unless the code you uploaded into Flash includes explicit code to initialise the native USB peripheral on the chip, the native USB port will do... ABSOLUTELY NOTHING AT ALL!!!  (Other than to perhaps supply power).  The USB 'light switch' is OFF... Nobody is home!!!

Any questions yet???  Just ask!!!

When you first apply power to a SAM3X8E CPU, it's in a pretty 'dumb' mode.  It's positively CRAWLING along at a snails pace using a comparatively slow (and not very accurate) internal RC clock oscillator.  It has to be explicitly told by the bootstrap code to fire up the external oscillator and PLL and then wait for these to 'stabilise' before switching into 'warp drive'.  Then it can start achieving its peak performance.  These actions are transparent to an Arduino sketch as they're handled 'behind the scenes' by linking in a chunk of code commonly known as CRT (the 'C' RunTime code) which prepares the CPU to rock and roll.
I completely bypass all of the Arduino / Atmel CRT preferring to 'roll my own' so that I know for a fact which peripherals ARE initialised (and just as importantly, which ones AREN'T).  Furthermore, my CRT code intentionally copies the relevant code from Flash into RAM since RAM runs at ZERO wait states.  Sure, running from Flash IS pretty quick and is effectively near zero wait states MOST of the time, but running from RAM gives me zero wait states ALL the time (and by inference, makes the code timing that fraction more deterministic).  Did I actually NEED to roll my own CRT???  I can almost guarantee that the answer is a resounding NO!  However, I've learned HEAPS more about the beast by doing so.

shubhambora14

How do i read data at native usb port of arduino due???

Go Up