MAX32625PICO board UART overflow problem

[dale-roberts]

It seems that once the USB/serial UART "overflows" on the MAX32625PICO DAPLink board, from that point onward it only sends '*' asterisk characters to the host PC. The only way I've found to recover is to unplug and re-plug the USB to the MAX board.

Details. I am using a Windows PC (but this is almost certainly not a host problem) and the target MCU is sending two lines of text per second via DAPLink to the host, about 150 characters per second total, which works well. If I "disconnect" the Windows COM port in the terminal program for more than about 30 seconds, when I reconnect, the terminal program shows only '*' asterisks. If I disconnect for 25 seconds or less, then it always comes back correctly and shows the text from the MCU. This happens with at least two different terminal programs on Windows (TeraTerm and CoolTerm).

Preferred behavior: Either automatically recover (probably best), or perhaps allow the BREAK command to clear the error (less intuitive, requires specific knowledge to know how to recover).

In the DAPLink source code (max32620\uart.c), the buffer is 4096 characters, which would be filled in about 28 seconds at my rate of about 150 characters/sec, so this behavior is consistent with a software buffer overflow in the DAPLink code. I believe this portion of max32620\uart.c may be relevant (although I'm not clear whether this '32620' file, or max32625\uart.c is actually used for this board):

#define BUFFER_SIZE (4096)
...
void UART0_IRQHandler(void)
{
    /* Capture interrupt flag state at entry */
    uint32_t intfl = CdcAcmUart->intfl;
    /* Clear interrupts that will be serviced */
    CdcAcmUart->intfl = intfl;

    if (intfl & MXC_F_UART_INTFL_RX_FIFO_OVERFLOW) {
            read_buffer.data[read_buffer.idx_in++] = '*';
            read_buffer.idx_in &= (BUFFER_SIZE - 1);
            read_buffer.cnt_in++;
    }

It seems that an overflow condition causes the '*' to get written into the buffer, but that there is no way that I could find (short of power cycling) to clear the OVERFLOW flag.

If no one else can presently work on this, I could take a stab, but I got a little lost trying to figure out if Keil is currently the best/only option for compiling? Is the most expedient thing to install the 30-day trial of Keil, or is there a working open-source method for compiling? (I see that there is recent activity on this front, just not sure of status as of today)

Thanks for any pointers anyone might be able to give!

[flit]

cc @khariya @jessexm

@dale-roberts Keil and Arm Compiler 5 is the only supported toolchain on the master branch. However, the experimental_compilers branch has gcc support, which will eventually become the primary toolchain once testing is complete. Unfortunately, according to the compilers-test-status wiki page, it seems like the Maxim ports are currently not working under gcc.

[khariya]

@dale-roberts This was fixed in PR #735 and recently merged into master. I hope it helps.

[dale-roberts]

Thanks so much for the replies @flit and @khariya, and for the pointers to the status page, and the fix - and of course thanks also for the great effort in getting things over to gcc!

I should have posted a couple days ago - I was in fact able to install the experimental compilers branch on an Ubuntu VM (I'm Windows primarily), and (despite the status page!) it did seem to compile and run successfully, and indeed I found that the UART does not have the asterisks problem in the newer build.

The one combination I could not figure out (it may just be a matter of finding the right link again) is how to build for the MAX32625PICO board, but with the MAX32660 target, as they do on the MAX32625PICO Firmware Updates page. This would of course allow the drag-and-drop upload into the MAX32660 target through DAPLink. They only provide binaries on the Firmware page, and I can't seem to figure out if that was built with this GitHub source, or from another source, or a fork, or using specific options to the build script... I'm sure it's something simple I'm missing, but I'd be grateful for any pointers anyone can give where they might already have all the required configuration files for this particular combination of board and target.

[dale-roberts]

... okay, I'm going to close this, since it seems to be corrected in the latest GNU versions, and my last post was more of a development question, not specifically related to this already-resolved "issue".

Thank you both again for your help.

[khariya]

@dale-roberts I'm sorry I missed your question on MAX32660. This target is currently not supported.

[dale-roberts]

Okay, thanks, I'll just continue to program it via DAPLink for now, rather than attempting drag-n-drop/MSC.