I am user of Arduino Due. These days I tried using Atmel SAM3X8E ARM Cortex-M3 circuit to develop my own main board for an instrument. But I found that when I connect it through the USB native port to PC (windows 7), the PC can not find it. The schematic of this port I used is the same as the Due board.
Because the connection of USB connector to Atmel SAM3X8E ARM Cortex-M3 is straight forward, I don't know how to resolve this issue.
Could someone give me some suggestions?
For the native USB port to do anything, the chip has to be running some USB software. The Due bootloader does this, AND I think there is a built-in bootloader as well... See section 20 of the datasheet, and the GPNVM bits
what do you have connected to the tx0, rx0 pins. These two pins are used by the native port and nothing should be connected to these pens while programming using this port. If anything has to be connected to these ports, they should be in an inactive (High z) state. Also if the previous program repurposed these pins for any other purpose other than serial communication, you may have problems using it as a programming port. it is recommended that you avoid using these pins for any other purpose unless you have absolutely no choice. Although these pins can be repurposed for other functions, the main reason why these pins are broken out, is to provide a serial communication port, either a USB, RS 232 or Other type of serial port for your project.
promacjoe:
what do you have connected to the tx0, rx0 pins. These two pins are used by the native port and nothing should be connected to these pens while programming using this port. If anything has to be connected to these ports, they should be in an inactive (High z) state. Also if the previous program repurposed these pins for any other purpose other than serial communication, you may have problems using it as a programming port. it is recommended that you avoid using these pins for any other purpose unless you have absolutely no choice. Although these pins can be repurposed for other functions, the main reason why these pins are broken out, is to provide a serial communication port, either a USB, RS 232 or Other type of serial port for your project.
Not so, the Due USB "programming port" has "front processor" 16U2 - interfacing USB plug / port to the SAM3X8E tx0 / rx0 pins. The 16U2 does the magic of converting USB to plain ASCII for the Due to do some tasks, one of them being the bootload.
The mini "native USB" port connects to true USB hardware implemented on the SAM3X8E chip and as such it needs to be properly programmed in software.
There are , to my knowledge , two VERY limited, but functional pieces of such software available - one controlling USB keyboard and the other USB mouse.
Vaclav:
Not so, the Due USB "programming port" has "front processor" 16U2 - interfacing USB plug / port to the SAM3X8E tx0 / rx0 pins. The 16U2 does the magic of converting USB to plain ASCII for the Due to do some tasks, one of them being the bootload.
And how, do you suppose, the SAM is actually connected to the 16U2? It is through Serial0, which uses digital pins D0 and D1! So if D0 and/or D1 are connected to something else, Serial will not work.
Regards,
Ray L.
Thank you very much for your replies!
I have attached part of my schematic in the attached file. Please have a look at it.
Because I want to use the native USB connector to write program into the SAM3X8E ARM Cortex-M3, but the computer can not find any port for it. Thus I can do nothing for it.
If I connect a brand new Arduino Due board to my PC, the PC will find it automatically. Before, I thought the PC can find the system board automatically when we solder a brand new SAM3X8E ARM Cortex-M3 circuit onto the PCB board.
If I choose another programming port, I need to write some firmware into the ATMEGA16U2.
PCB_Mainboard_v1_P12.pdf (103 KB)
FYI
"C:\Documents and Settings\Vaclav\My Documents\Downloads\usbdeview\USBDeview.exe"
The above program identifies the "native Due" port as "Bossa program port" with many details and it is installed by "obsolete" XP just fine.
Sorry, I cannot read your .pdf file.
How did you route the D+ and D- lines on the board? USB is very sensitive to the length of these wires. If you look very closely at an original Due, you will see little S-turns in one of those lines. These are called "meanders" and they make the length of the two of them identical.
Thank you very much for your replies!
I tried the USBDview.exe, it is a very good software. But it can not detect my devices.
When I route the D+ and D-, I already considered the issue of lengths.
I will do more testing today.
Finally, I found that the VBus (Pin 39) is not really connected to the XUSB (iput voltage).
After I connect the VBus to +5V. The PC can detect the USB device, but it always can not install valid driver for it. When I open Arduino development software, it can not find the valid port yet.
ybs273:
Finally, I found that the VBus (Pin 39) is not really connected to the XUSB (iput voltage).
After I connect the VBus to +5V. The PC can detect the USB device, but it always can not install valid driver for it. When I open Arduino development software, it can not find the valid port yet.
I have been taking detour from my USB development, but here is something you may find useful.
I found it helpful to look at Due "native port" similar to "hardware serial" implemented on pins 0 and 1. As a combination of SAM's dedicated hardware with user implemented software.
So that is probably why USBDeview identifies only part of the USB initialization - each USB device carry bunch of stuff to send to the host as identification - USB calls those "descriptors".
Apparently the Due native port USB "name" is "Bossa programming port"
Your software has to request these descriptors to initialize the USB "pipeline" - another USB term I may not be using correctly.
I believe simply connecting the host to device is not sufficient to do anything intelligent, maybe just part of it.
Still I would recommend to you to try one of the "canned" USB Due examples - I had some luck with both - keyboard or mouse.
Here is another part of the USB puzzle.
I think the key / password is this
#if defined(USBCON)
If we can find WHAT / WHERE is "USBCON" defined we are at the starting line.
Here is a trace from yet another discussion about the function of the USBCON.
So - where is Due "mcu header file "??
USBCON will be defined in the mcu header file if the mcu has USB hardware. It is a register to configure the USB hardware, the definition is the register address. Without the mcu hardware I doubt the USB API will be of much use.
Did not find USBCON in header file , but compiler found it defined.
SO the USB API can be used, look in HID files for more.
Did not find USBCON in header file , but compiler found it defined.
USBCON is defined on the compile command line, derived from platform.txt
I don't see why it should have anything to do with the USB bootloader that should be present (and run) on an otherwise blank chip...
westfw:
USBCON is defined on the compile command line, derived from platform.txtMakes sense.
I don't see why it should have anything to do with the USB bootloader that should be present (and run) on an otherwise blank chip...
The OP is not about boot-loader port , it is about "native USB" port usage.
westfw:
USBCON is defined on the compile command line, derived from platform.txt
I don't see why it should have anything to do with the USB bootloader that should be present (and run) on an otherwise blank chip...
The DUE doesn't have a bootloader like the AVR chips do. It takes serial programming directly. It's more like a hardcoded bootloader that can't be removed.
The Due provides both ports because it requires a running sketch to operate the 'native' USB port. If your program locks up, then you can't load a new program over USB and must use the programming port.
This is certainly the case for the Teensy 3.x chips.
MorganS:
The DUE doesn't have a bootloader like the AVR chips do. It takes serial programming directly. It's more like a hardcoded bootloader that can't be removed.The Due provides both ports because it requires a running sketch to operate the 'native' USB port. If your program locks up, then you can't load a new program over USB and must use the programming port.
This is certainly the case for the Teensy 3.x chips.
MorganS:
The DUE doesn't have a bootloader like the AVR chips do. It takes serial programming directly. It's more like a hardcoded bootloader that can't be removed.The Due provides both ports because it requires a running sketch to operate the 'native' USB port. If your program locks up, then you can't load a new program over USB and must use the programming port.
This is certainly the case for the Teensy 3.x chips.
Good point, that would also explain the "Bossa" name in part of the USB descriptor used on native port.
Those folks at ATmel apparently know what they are doing.