Serial USB with Java - Programming port issue - Complex test with HDLC

Hello cmaglie,

Per your private mail request in order for your team to troubleshoot the USB programming port issue found in my private laboratory, please find the link to a simplified Serial Protocol between any arduino (UNO, MEGA,...) and a Java GUI which has been running on PC and Mac for years in my power electronics open sourced projects (ferro-resonance and plasma-resonance).

You would need only wire 4 LEDS on pins 24, 28, 32 and 36 each in serie with 1K resistors in sink mode to verify that SerPro for some reason, does not correctly communicate with java GUI on my MacBook Air and iMac.

LED24 for LinkUp LED28 for CRCerror (HDLC with 16 bits CRC) LED32 for Xmit data LED36 for Rcv data

When the link is first correctly established, LED24 will stay ON then using the left two GUI slider will make blink LED24 otherwise, using the right sliders will make blink the LED28.

P.S.1. Prior moving any sliders, the Java GUI will receive from arduino then display some PWM frequencies and duty cycle, namely 24450 Hz, 37%, 10%...

P.S.2. After using left sliders, LED24 will then always stay OFF except when moving left sliders

One example of very complex use of multiple timers on arduino MEGA along with homemade FPGA's being isolated barrier from more than 7000 peak of reactive power (loose-coupled Hartley oscillator), please see this specific video on my YouTube channel

When compiling and downloading my arduino DUE the IDE, everything goes OK except all the LED's keep flashing hence serial HDLC link is never established, many CRC errors, constant Xmit and Rcv for ever.

Thank you in advance for your time, Albert

P.S. I'm sure most users are aware to install special USB Java libraries required for USB protocol working, with PC I don't know but with Macintosh, one needs two libs, namely: - librxtxSerial.jnilib in [u]same[/u] folder where ElectroShaman.jar is launched due to Mac OS issue - RXTXcomm.jar in Libaries/Java/Extensions/

I've managed to get it running on Linux and I can verify the problem. I've run the code on a Mega 1280 (which worked) and on a Due (which didn't work). I then changed the code to use Serial1 on the Due, and used the Mega as a dumb USB-Serial port, and that worked properly. I also tried an Arduino Uno for USB-Serial, which also worked properly. (If anyone tries this, don't forget the level converters)

From that I'd conclude that the sketch itself is correct and the java code is probably OK, so there must be something odd going on with serial on the Due. Unfortunately I don't have the expertise to look into that. But I thought it would be worth just saying that I can confirm the problem.

Many thanks Stimmer to have 3rd party independent tested the serial USB issue on DUE's programming port and validated it works as i've claimed on UNU, MEGA 1280 and MEGA 2560 (all rev).

As I've mentioned before, this SerPro has been used on critical software and power electronics for open source alternative scientific projects in many countries for more than 2 years wether Mac, PC or Linux.

Let's hope the arduino team resolves the issue.

On a side note, you might want to see the type of critical software I'm using with MEGA applied to extreme power electronics going up to 3 KVAR's (public) and 10 KVAR's (private). For example, in this video I'm using the four 16-bits MEGA timers, each being specifically delayed 90°, 180°, 270° with less than 62.5 ns time jitter.

P.S.1. In fact, there really SIX 16-bit timers, two of them are being emulated by my specific protoshield using some 74HCxy chips

P.S.2. You might notice from time 7min 0s in the video that actually I live update by ISR (Interrupt Software Routines) all the FOUR internal 16-bit timers register so you'll se a global frequency sweeping up. Due to the special topology of my circuit, this is equivalent to have arduino MEGA-generate phase locked 8 independent PWM rails aka 8 channel frequency generator.

Just hoping the arduino team will soon fix the USB serial issue (programming port) via a new IDE release, at least on my side I cannot afford to migrate my actual project MEGA software using very advanced timer register tricks since i'm shuttling more than 5000 VAR's with my igbt's drivers, blue smoking and $$$ gone !

Once DUE serial USB will be OK, I'll look deeper on the DUE timers which i feel from datasheet are very very interesting with fascinating new features not feasible with MEGA, same with DAC's and ADC's.

You'll notice some of my boards hosting the MEGA as piggy board are in fact fully space compatible with DUE, [u]the board were designed more than 1 year ago betting DUE will come up.[/u]

About MEGA used to induce anomalous plasma-resonance, this old video might be of interest


Could you please try the following:

1) Start the Java program 2) Hold down the Due RESET button, and keep it held down 3) Select the Due serial port from the menu in the java program 4) Wait a few seconds for a few "No response" messages 5) Release the RESET button

When I do this, the program appears to run normally.

I think the problem is the same as the one we have noticed here before - when the serial port is opened the Due sends a few lines of serial output, then resets, then starts again. I don't think that problem is solved yet.

Many thanks stimmer to contribute on this issue.

Good news and bad news.

Good news: I've done per your instructions and now my Java GUI receives all the local PWM parameters from arduino DUE, upon changing values via sliders, my Java GUI does send new parameters to arduino DUE, at least I see proper reaction of my LED's.

Bad news: when i connect DUE to my iMac USB (no launching of ElectroShaman GUI), the CRCerror LED is faintly ON so for some reason, it detects incorrect HDLC frame (this does NOT happen with same IDE on MEGA or UNO). Now when I launch my Java GUI per your special reset instruction sequence, the GUI sliders will properly light ON the LED's except the CRCerror led stays a bit ON (not normal) and most problematic, the Linkup LED never lights ON.

I cannot see why there would be a bug in my IDE or Java explaining partial CRCerrors, maybe there is bug but I still have serious doubt (please verify or debunk if I'm wrong) because the way i've programmed SerPro is to be free of any endianness issue.

My feeling but just intuitive, there are once in a while garbage data flowing through programming USB port whatever application and that is major issue, not only for my project but is general issue for arduino community.

stimmer: I think the problem is the same as the one we have noticed here before - when the serial port is opened the Due sends a few lines of serial output, then resets, then starts again. I don't think that problem is solved yet.

Do you think this can be solved by software or is it built-in hardware on arduino DUE board ?

P.S. I've just noticed that also Xmit LED does slight lights ON which is NOT normal !