Go Down

Topic: Some help with the native serial connection (solved) (Read 1 time) previous topic - next topic

fra77x

I'm trying to use the native port to communicate with the Due.

The problem is that when I first upload the program (and the uploading finishes), the native Serial Com is disconnected (windows says this device malfunctioned").

I have to disconnect and reconnect the native USB cable.

After that the connection works ok, i can get serial data in my C/windows app and when I close my program and re-run it the Due does not reset (so it works as it should)

So anyone can help, why windows loses the connection with Due's native port when I upload the program.

I upload via the programming port.

Thanks.


EDIT: It seems that (what i describe as a problem) it is normal behaviour because at the time the ARM is reprogrammed it can't communicate with the host computer.






ard_newbie


If you need to use both Serial and SerialUSB at the same time, you have to open 2 different sessions of your IDE.

In your skectch, you will have a Serial.begin(250000); and some Serial.print("Print from programming port"); and a SerialUSB.begin(); and some SerialUSB.print("Print from native USB port");

Then you open a first session with the programming port, hook a USB cable between your PC and the programming port socket, hook another USB cable between your PC and the native USB socket.

In a first IDE session, select board Arduino DUE programming port, select a com "programming" port, then upload your skecth. You will see in this IDE window --> Print from programming port

From your IDE short cut, right click and open another IDE session, select board Arduino DUE native USB port, select a com "USB native" port. You will see in this IDE window --> Print from native port


fra77x

Thanks,

yes I know how to use both programming and native port at the same time. What I tried to describe as a problem (the native port disconnecting on program upload), I think is normal, because when the ARM is re-programmed it can't communicate with the host computer.

Anyway, It's not a big deal to disconnect and reconnect the cable.

I'm programming a simple oscilloscope for the Due's analog inputs, it sends the data via USBserial to a windows app that displays the data. It sends 12bit values (the analog inputs of Due are capable of 12bit ADC).
I will try to add all 12 channels. When finished I will upload the code here if anyone is interested.





ard_newbie


roundseven

Have the same problem with the Due and OSX El Capitan. The native port is present, but as soon as i uploaded the scetch, its gone. Reconnect doen't help, i have to restart the computer. Then the same thing happens. I need to work with the native port cause i use the MIDIUSB library but his way of working is not very effective. Had anyone the same problem with El Capitan and solved it? Thanx!

AdderD

Keep in mind that the Due is weird in that the USB stack is part of your sketch. The SAM3X processor itself has USB connectivity. There is no external chip providing USB, it is cooked right into the chip and the USB software is running on the chip along with your sketch. Because of this, if your sketch soils the bed then USB will die. This makes the native port potentially difficult when you are testing because you can break the native USB port and then how do you upload a new sketch to fix it? Well, the answer is you erase the chip. With the chip erased it'll run a bootloader from static ROM and that bootloader has a non-corruptible USB stack that will provide a USB port you can upload to.

So, my suggestion would be to erase the chip then upload a very simple sketch - maybe just one that toggles the LED or prints something. Like:

Code: [Select]

void setup()
{
   delay(3000);
}

void loop()
{
   SerialUSB.println("It works");
   delay(1000);
}


If that sketch gives you a reliable serial port whenever you plug your Due in then the problem was your sketch. If it does not then suspect your USB cord. I don't care if you bought it from the pope or Jesus came down from Heaven and gave you that cord. USB cords are prone to be junk and you should always suspect a bad USB cord if you are having trouble. Seriously, bad USB cords are the root of all evil.

roundseven

Thank you AdderD, that solved my problem!

I uploaded this little sketch to erase the chip

void setup() {}
void loop() {}

and the native usb port showed up again.  Then i figured out the problem in my sketch and found out that it was a memory overrun. I shrunked my main struct and now its working stable.

Go Up