And I’m unable to copy to clipboard from the uart file
And I’m unable to attach the otii file here because it’s too big.
Playing with it, I think the problem is because my device is sending the prompt with no newline, like:
container proc >
and then the rest of the text follows later once I’ve entered a line. It’s getting confused by this.
This is a regression bug in the latest software (2.5.0)
Could you create a case and attach the project there. If possible please crop the project first so you only keep an area of the project where the problem is. Make sure you save it first before you decimate the data so you can go back to the original if the problem disappears when cropping.
This has been corrected in Software 2.5.1 released today.
Hi, I am also facing this issue in 2.5.1 on Mac OS
It seems to work on the first few lines of the uart stream but them it goes out of sync.
See attachment. The micro sends two messages at 423ms since restart but the software puts the second one way ahead.
Thanks!
Hmm, that’s odd… I’m getting the feeling that the embedded timestamp is in seconds, not milliseconds though? That being said, could there possibly be additional characters at the end of each line? Can you see NUL characters or something similar if you enable “Show control characters” under Display Options? I would expect at least CR and LF to show up which is to be expected, but we have seen NUL characters sneaking in on more than one occasion.
One UART change that went into the 2.5.0/2.5.1 software was that we wanted to make sure that the timestamp corresponds to the earliest character on the line, previously the software would take the last timestamp, which normally isn’t what is desired. In this case that “feature” might have masked a different issue. If a NUL character is trailing the LF after each line, that NUL character will end up on the next line and the corresponding (early) timestamp will follow it.
If you can share the otii project then we can take a closer look at how the UART data is structured.
