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.
I could be wrong but personally feel what ever different issues happened with USB.serial are not only related to buffer sizing.
As I've explained on some the threads a few weeks ago, the test i'm using is quite wide since it consists to have a Java GUI dialog with arduino mega via USB using SerPro protocol open sourced by Alvaro Lopes. In fact, this SerPro protocol is a RX/TX using an HDLC with 16 bits CRC, it has been running on different projects wether on PC or Macintosh for a few years, able to transfer one way or the other way many variables, single, frames... re-transmit if errors and so until the packets get through the link.
A while ago, i did try the protocol to my arduino DUE, in fact the way it has programmed in C and C++ is NOT dependent wether arduino DUE or arduino MEGA or arduino UNO but it never worked with DUE under IDE 1.5.1
I'm eager to have access soon to the new IDE to benchmark test if all the USB issues have been resolved.
P.S. 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.
Once DUE will become more mature and guess as you said, the Atmel datasheet, such project will be easier with more timers and software possibilities with incredible few ns precision jitter.
I do agree that the Sam... datasheet register are not very detailed, maybe a mix of Atmel releasing too early beta datasheet or whatever.
You might want see this video where I'm using the four 16-bits MEGA timers, each being specifically delayed 90°, 180°, 270° with less than 62.5 ns
P.S. In fact, there really SIX 16-bit timers, two of them are being emulated by my specific protoshield using some 74HCxy chips
Just hoping the arduino team will soon fix the USB serial issue 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.
I really don't understand why you guys are not fully using the the complete potential of timer possibilities, of course requires fine register initialization but you could get very precise high frequency PWM even beyond 500 KHz or 1 MHz.
I do have an arduino DUE but as explained on other threads recently, I cannot download my actual MEGA projects using advanced arduino mega timer management because USB link of DUE is full of bugs.
Again I insist, just program the proper WAVESEL value and other registers, there is NO need to make interrupts slowing down and skewing the PWM jitter precision if using a timer, in particular with DUE being much more sophisticated timer possibilities than MEGA !
it seems to me you're subject to different waveform coding, with arduino mega look at fast PWM versus phase correct PWM but also frequency & phase correct PWM. The last 2 cases will divide by 2 the actual timer frequency generation.
I've quicked look on SAM3X... datasheet for the equivalent story, same except they use WAVSEL to choose whatever mode. Later on the datasheet, they also speak of center align or left align.
So there is no bug, just program correctly the registers...
Here are some threads dealing with I think a more global issue related to Programmer USB port, in my case, I use MacBook Air where my code has been running for years on mega, it is Serial protocol using HDLC on to of USB.