MSP430FR2153: Solving MSP430 Back-channel UART buffering delay on Windows 10

Hi Bryce,

Yes, it bugs me all the time.  I asked our SW engineering team once for help and they indicated it was "Windows USB CDC" behavior.  Not sure I believe that,  I don't have a way to confirm if there is a latency caused by the MSP430F5528 (acting as programmer/debugger/back-channel UAR) on the launchpad. If I could measure the USB side to see when the received UART data appears on the USB side that would be helpful.  Perhaps there is someone in the community that has experience with this.

When I complained, er, described this a few years ago, I was told that debugger traffic got priority over the USB. The implication was that  there were no plans to fix it. I think it started about the time EnergyTrace appeared. (The discussion is somewhere back in the Forum, but I don't remember enough keywords to find it.)

My only observations are:

1) If you disconnect the debugger (software) there are no delays over the UART..

2) There appears to be a ~64-byte burst forwarding, so if you're putting out a fair amount of data the delay isn't really noticeable.

[Edit: I first saw this on Win7, so it's not strictly a Win10 thing.]

Yeah, it's about 64 byte burst forwarding, or a 2 second delay.

"Disconnect from target" in the CCS debugger stops the program, so that's no good.
Disabling EnergyTrace I can't figure out.
However, "disconnect from target" then loading my firmware via UniFlash is working well.  There's no buffering or delay effective visible
(but I have to wait several seconds for the MSP Application Serial Port to appear in to Windows 10).

How can I run a non-debug session from within CCS Desktop?

Just to clear this up, it is problem related to FET software / firmware. Not to PC side any OS or driver, or to MSP430 USB hardware module, 64 byte CDC packet size, whatever.

My old MSP430F5510 based flasher was able to do 4 Mbps log from 2 CDC-UART ports (in parallel) on any OS (down to XP SP2). Yes, it is log from released / free running device, but waiting 2-3 seconds on 19200 bps, today in 2020, no way.

My observation: Disconnecting (square box button) while at a breakpoint leaves the MCU program stopped. Doing so while the MCU is running leaves it running. There's also the reset button.

Hi Bryce,

I have confirmed that while operating in debugger mode there will be delays in data transmission due to bandwidth required for the debugger to handle all of the debug activity and UART.  If you try without the debugger or exit debug mode, the delay should go away.

Hi Bryce,

I haven’t heard from you for a couple of days now, so I’m assuming you were able to move forward with your project.
For this reason I'm changing the status of this posting to RESOLVED.

If this isn’t the case, please click the "This did NOT resolve my issue" button and reply to this thread with more information.
If this thread locks, please click the "Ask a related question" button and in the new thread describe the current status of your issue and any additional details you may have to assist us in helping to solve your issues.

While this explains the issue, it's not a resolution.

How about documenting this behavior?

Is there a technical way to say I'd like less priority on the debugger and more on the UART?  Does a faster PC or a USB 3.0 interface solve the problem?

Bryce Nesbitt said:

Does a faster PC or a USB 3.0 interface solve the problem?

Bryce Nesbitt said:

Is there a technical way to say I'd like less priority on the debugger and more on the UART?

void switchDebugerOff()
{
    TA1CTL &= ~TAIE;
    TB0CTL &= ~TBIE;
    TA0CTL &= ~TAIE;

    loopInfos_.Scheduler = dummy_Scheduler;
    loopInfos_.UsbLoop = USB_MainLoop;
    debuggerOff = 1;
}


void switchDebugerOn()
{
    loopInfos_.Scheduler = V3OP_Scheduler;
    loopInfos_.UsbLoop = dummy_UsbLoop;
    TA1CTL |= TAIE;
    TB0CTL |= TBIE;
    TA0CTL |= TAIE;
    debuggerOff = 0;
}

void switchOnUart()
{
    if(!debuggerOff)
    {
        loopInfos_.Scheduler = V3OP_Scheduler;
        loopInfos_.UsbLoop = USB_MainLoop;
    }
}

dummy_UsbLoop() is an empty function. USB_MainLoop() calls COM_BASE_Loop(). COM_BASE_Loop() will send characters received from the UART over USB every 1500 (EJECT) calls.

Whereas when the debugger is active received characters appear to only be sent by COM_BASE_Receive() when the receive buffer contains COM_FIFOSIZE bytes. Where for a MSP_FET COM_FIFOSIZE is set to 256. Where COM_BASE_Receive() is called in response to a UART receive interrupt.

I.e. from a look at the structure at the MSP-FET firmware can understand why the UART reception is buffered when the debugger is active, but can't see any mechanism in the existing source code to allow a way of selecting the relative priority of the debugger .vs. UART.

Bryce Nesbitt said:

Does a faster PC or a USB 3.0 interface solve the problem?

Hi Bryce,

This limitation is documented in the MSP Debuggers User's Guide, section 5.6.2.