Coolterm hangs - receive buffer too small ? (macos)

[maxterm]

Hi,

I’m using CoolTerm 2.4.0 on MacOS 10.14 Mojave (Mac Mini 2012) and have run into a significant issue that I'm able to reproduce. I'm trying to program the firmware using a USB TTL adapter connected to the serial debug port of my Synology NAS.

CoolTerm hangs during the BIOS chip writing process with the rtkspi tool from the U-Boot bootloader. This process takes about 7:20 minutes, showing a series of dots until it completes. However, around 6 minutes into the process, terminal output freezes, and the Realtek> prompt never appears again. This forces me to reconnect, which interrupts the procedure and risks bricking the device.

I've been using ZTerm for years without such issues, but wanted to try CoolTerm, since it's cross-platform and has a nice interface. I’ve found that increasing the receive buffer from the default 10,000 to 100,000 seems to prevent the freezing.

Is this a known issue? Is it platform specific?

Thanks!

[roger]

Hi,

I'm not aware of the size of the receive buffer causing any sort of freezing of the application. I also assume that your use case involves mostly sending data rather than receiving? Is all that is being received a series of dots? How frequently does your target send back these dots?

Roger

[maxterm]

Hi Roger,

Here's some more info:

The serial console is used for entering commands and feedback. The actual firmware data is transferred via tftp. The TFTP command streams the remote file (bios flash) to a memory address on the device. The RTKSP utility then erases the existing BIOS (chip) and then writes the data from RAM. For example:

Realtek> tftp 0x10000000 mybios.bin
Realtek> rtkspi erase 0x00000000 0x01000000
Realtek> rtkspi write 0x00000000 0x10000000 0x01000000

During these operations, I receive progress feedback, such as #, eccc, or dots. The RTKSPI WRITE command outputs dots for approximately 7:15 minutes, running at about 80 dots every 2 seconds, with the communication set to 115200 baud. CoolTerm always freezes somewhere at minute 6:00. I'm not really sure, but when this happens, I think the CoolTerm byte counter starts to increase rapidly and never stops.

I tried three times and was able to reproduce the problem. Quitting CoolTerm luckily brought the Realtek prompt back, and the problem did not lock up serial communication, potentially bricking my device. Increasing the receive buffer, as I previously mentioned, appears to work around the issue.

I also completed the task using the MacOS screen utility, which worked flawlessly, but I was looking for a cross-platform solution. The screen session log file was around 30K.

Thanks!

[roger]

Thanks for the explanation. Could you send me the screen session log file to my e-mail address (you can find it in the "About CoolTerm" box)? I'll try to rig up something that simulates your debug port so that I can receive the same data and see what happens.

The receive buffer set to 10k really shouldn't cause any problems, even if you receive 30k worth of data. Anything 'older' than the most recent 10k bytes should simply be dropped. The byte counter increase does indicate that it is still receiving data, so perhaps this is an issue with the display only? Once the display freezes, what happens if you switch to hex view mode?

Out of curiosity, could you set the buffer size to 1k and see what happens?

Roger

[maxterm]

I just sent you the log. Let's see if it provides any clues. If not, I'm happy to do some more testing, but prefer not to re-flash the firmware, if possible.

It appears the RTKSPI WRITE command actually displays a dot for every kilobyte it writes, producing 16385 dots while writing the bios flash, which is 16 MB total. The dots automatically wrap in the CoolTerm window, but are actually a single line in the log.

Perhaps another issue and not related, but worth mentioning: I need to set the "Enter Key" in the Terminal options to CR to avoid double prompting when hitting the Return key. It would help if CoolTerm could adjust to Unix or DOS line endings of the host computer accordingly. However, I still get empty lines when prompted for username and password. Also, I see a dot and space when a line starts with 5 spaces, when it should be a tab and single space, or just 5 spaces.

Thanks a lot for your time.

[roger]

Thanks for the log.

I wrote a macro that sends 16385 individual dots followed by a 20ms delay on one serial port. This process takes a little over 7.5 minutes. This data is then received by another serial port in another CoolTerm window. I didn't observer any hanging, but I did observe something that could be interpreted as such. Once the receive buffer is full, a new received byte will cause the "oldest" byte in the beginning of the buffer to be removed from the buffer to make room for the new byte, which is then added to the end of the buffer. The display is then updated with the new buffer contents. I.e. in this particular case, when there are 10,000 dots in the buffer and new dots are being received, there will always be 10,000 dots in the buffer. Thus, the display contents will always look the same, i.e. the cursor at the end of the received data is always be in the same place. This does look like the display is no longer being updated when it actually is. The byte counter is still being updated. but the display essentially looks frozen because the receive buffer contents keep looking exactly the same every time a new dot arrives. However, if I let it finish, the byte counter will stop after the 16385th has been received. Any other bytes received after that display just fine. Is that what may be happening with your setup? You can verify that by hitting the "Clear Data" button when it looks frozen. This will empty the buffer, and the display will start filling again from the top.

Seeing a dot and a space when you expect to see a TAB and a space or just 5 spaces, means that you probably have "Non-printable characters" option set to "convert", which will convert TABs to dots. Change that option to "ignore".

I'm not sure what you mean by getting empty lines when prompted for username and password. Can you elaborate on that? It would also be helpful to know what is being sent back by your target device during that interaction. You can see the a lot more detail in hex view mode, specifically the ASCII codes for every byte that is received.

Roger

[maxterm]

Hi,

It did not look like the terminal was not updating or frozen after increasing the Receive buffer. It just continued to print dots, starting on a new blank line when reaching the end of the screen, effectively scrolling past contents off the screen (into the buffer). Once RTKSPI finished, I was left at the Realtek prompt.

When the problem occurred, and I certainly let it sit there for more than 20 minutes, hoping it would eventually finish, but the Realtek prompt would not reappear. Hitting the Return key or CTRL/C had no effect. Pushing the Disconnect and Reconnect buttons also made no difference. The only way to get the input back was to quit CoolTerm and open it again. I could then see some *INTERRUPT* messages, probably from past CTRL/C and finally got the the Realtek prompt back. So I tried again, and ran into the same issue, until I increased the Receive buffer.

Maybe the issue is local or platform specific. I will try to reproduce the issue in my set up, without writing the firmware. I have another USB/TTL converter and can use it on another system to generate data. I going to use Linux bash, like:

Code: Select all

for ((i=1; i<=30000; i++)); do
    echo -n "." > /dev/cu.usbserial...
    sleep 0.025
done

I'm currently busy, but should be able to follow-up within a few days.

Regarding the empty lines when prompted for username and password, I have a couple screenshots that I will send you shortly.

Best regards.

[roger]

Thanks for the screenshots. Can you switch over to hex view to see what's been sent back by your target? I wonder if it's sending extra CR characters. You may want to try enabling the "Handle CR as real Carriage Return" option under "Data Handling".

I also noticed some ANSI escape sequences in your terminal window. You can enable the "Filter ANSI Escape Sequences" options under "Data Handling" to prevent those from showing up in the terminal.

[maxterm]

Here's my result streaming from another serial port into CoolTerm. I have set the Receive Buffer to 1000 and ran a for loop in bash to sent dots, as mentioned in my previous post.

It appears screen output stops somewhere between 900 - 1000. At that point there's no more screen update and the cursor remains in the middle of the terminal screen - it's not at the end or beginning of a line, or end of the terminal screen. Actually, 1000/80 = 12.5, which is right in the middle of the screen (80/25).

Shouldn't it continue printing dots, starting on a new empty line after reaching the end of the line, scrolling the screen up one line? There's also no update if I interrupt the procedure and execute it again. The screen remains the same with the cursor sitting in the middle of the screen.

I have to send something else than a dot for the cursor to advance, filling the remaining space of the line, and new lines. It's like the program concludes you have received xxx number of the same character (reaching the limit of the buffer) and then decides to ignore the same character, unless you give it something else in-between.

Alternatively, as you wrote, pressing the Clear Data button revives the output.

However, this does not explain the issue I initially described with the Realtek prompt not reappearing. Could it be that the RTKSPI utility expects a specific number of characters in the output (like dots) before it decides that the operation is complete and returns control back to the user?

Thanks!

[maxterm]

Hex view is a quit useful feature.

Here's what I see at the login prompt:

0D 0D 0A 44 53 32 32 30 6A 20 6C 6F 67 69 6E 3A 20 0D 0D 0A 44 53 32 32 30 6A 20 6C 6F 67 69 6E 3A 20

Enabling the "Handle CR (0D) as real Carriage Return" option under "Data Handling" removed the extra empty lines. Perhaps this should be the default under MacOS and Linux.