DUE SERIAL_PORT -1 hangs

[Bob-the-Kuhn]

@ejtagle - got another one where I need your help.

If I have the host interface on the native port (SERIAL_PORT -1) I have these two situations: 1) On power up or reset the boot screen doesn't come up on the LCD until I connect via Repetier Host or Pronterface. Once the LCD is up & running then the USB mass storage device comes up on Windows. 2) When I disconnect in Repetier Host the controller will hang 20-25 seconds later. When I disconnect in Pronterface it continues to run.

In both cases the controller is stuck in this loop (lines 95-97 in file MarlinSerialUSB_Due.cpp):

93  void MarlinSerialUSB::write(const uint8_t c) {
94  
95    while (usb_task_cdc_isenabled() &&
96          !udi_cdc_is_tx_ready()) {
97    };

This may not be related & it's definitely not a problem for the user ... If I move the USB cable from the native port to the programming port then the LCD comes up within a second of powering up, Repetier Host connects via the programming port and there's no hang when Repetier Host disconnects. This is with SERIAL_PORT still set to -1.

[Bob-the-Kuhn]

If I put a timeout in that loop then it takes 4 seconds after reset for the boot screen to come up and, 25 after disconnecting Repetier Host, the LCD update rate slows from 0.99 Seconds to 1.18 seconds).

This is with the WDT enabled.

[ejtagle]

Very good analisys... :D ... I´ve been having similar problems... Let me find out...

[Bob-the-Kuhn]

The startup problem is because Marlin is trying to transmit info to the host during the setup phase.

Once it gets by line 687 in Marlin.cpp it hangs in the USB send loop.

685    #if NUM_SERIAL > 0
686      uint32_t serial_connect_timeout = millis() + 1000UL;
687      while(!MYSERIAL0 && PENDING(millis(), serial_connect_timeout)) { /*nada*/ }

[ejtagle]

My guess here is the following: usb_task_cdc_isenabled() will return TRUE when the CDC port is recognized and configured by the host PC. Note that "recognized and configured" does NOT mean the port is actually open by an application! udi_cdc_is_tx_ready() returns TRUE when the PC has enough room on its RX buffers...

[ejtagle]

(https://www.avrfreaks.net/forum/xmega-and-usb-cdc-blocking-writes) ... Basically, windows is using endpoint handshake to forbid Marlin sending more data. That prevents data loss... But... ;)

No program on the PC is consuming Serial port data, so, it will stop Marlin until a program starts consuming. There is an easy fix ... Do not let Marlin send anything if port is not OPEN. That means listening to DTR signal also...

[ejtagle]

The question is... What do we want to do when no user application is listening to Marlin serial messages ? ... Programming port seems to delay transfer with an internal buffer... We dont have that internal buffer. I could implement it, so we can accumulate messages until DTR is set high, or i could just avoid outputting data if port is not open on the PC side (DTR=0)

[Bob-the-Kuhn]

let me see if I see the startup messages on LPC1768.

[Bob-the-Kuhn]

The LPC1768 does NOT display the startup messages.

The DUE programming port, when serial is set to 0, does NOT display the startup messages.

The 2560 does display the startup messages. It spits out 1098 characters plus the CR and LF characters.

I vote to throw away everything until the host is listening.

[ejtagle]

Done!... Let me post a PR so you get the changes 👍 and you can test them!

[ejtagle]

PR #10110 . This is all your own merit, @Bob-the-Kuhn , as you traced the problem. The implementation of the fix was not a big deal 👍

[Bob-the-Kuhn]

That fixes both problems!!!

I have a J-LINK which comes in very handy for some types of debugging.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.