Has any one seen any recent issues with receiving data on Serial1?
I was originally testing a chip-to-chip interface running 115200. Ever so often a byte would miss. I checked my logic analyzer and the timing seemed to be off. I turned the baud down to 9600 and it’s still happening. (Albeit not as often )
My loop function is some simple test code:
// Process dmx
while(Serial.available()) {
char c = Serial.read();
Serial1.write(c);
}
// Echo on the other end.
if( Serial1.available()) Serial.write(Serial1.read());
I’m initializing some GPIOS at the top. of the application code. I had the logger enabled (and then look it out for debug) The chip I’m working with doesn’t have a crystal (it’s using an internal RC).
This is only a command protocol so I’m only sending max 4 bytes at a time over a long period. So overrun shouldn’t be a problem. I’m running 1.4.0 on a Xenon.
My guess is that it’s a timing issue or that there’s some weird RX bug that I’ve never seen before.
Can you try in SYSTEM_MODE(SEMI_AUTOMATIC) and/or put your Serial.write() into another while rather than if?
I guess your code above is placed in loop() and with cloud connection you are only readying one byte on each iteration of loop().
I have no feeling for the frequency on Xenons, but on Photons this would be ~1000Hz and on Electron 100Hz.
(oops, didn’t read the text about the shortness of your messages following the screenshot before posting )
Thanks @ScruffR. Yea I originally had it in a while loop. Like the top one.
Such a bummer, it’s the last bit of work I had to finish to get another project working.
I’ll keep working at it. I’ll probably try another Nordic board to see if there’s problems there as well. The frames could be just off enough to be corrupted for the NRF52840’s USART peripheral.
If you or anyone else has any insight I’m all eyes and ears.
I am in a project test phase now with a 115200 serial connection to a 3rd party product. 64byte message with checksum and ascii control codes in use. Thousands of messages so far and no issues using Xenon and Argon with Eth wings. SYSTEM_THREAD(ENABLED) & SYSTEM_MODE(SEM_AUTOMATIC). My read function is called from loop() and then the function does a
So this does focus the serial read on emptying the buffer.
In a separate test branch of the code I have also used the SerialBufferRk library in the same fashion and it also works really well.
I am leaning towards a hardware issue in your case as serial timing does cater for a fair bit of jitter as the EIA spec allows for ±4%. However the length of the cable and capacitace will deform the rising/traiing edges and cause issues - in your case the signal above is pretty clean, so that is not the likely issue.
Thanks for the input @shanevanj! That's what I'm thinking too. I did go back and measure it and the 9600 baud from my external device was more like 9601 which seems more than sufficient for the ±4%. I checked ground issues. Maybe there's some crazy common mode noise that's causing the issue that I'm not seeing.
Time to break out the oscilloscope and debug bit more.
I’ve got a project where we interface with 3rd party serial devices, and getting it all working was a major struggle. RK’s Serial Buffer fixed a lot of my issues. Also, couldn’t quite tell what the voltages are from your o-scope, but is your voltage hitting 0v for you 0’s? looks like it is, that was an issue I had though was my 3rd party device was strongly pulling up and the particle couldn’t drive the logic all the way to 0.
They’re all connected to the same reference (USB hub). The logic levels seem ok though. (3.3V/0V throughout)
Everything here isn’t connected by more than a few inches of wire. As a test I flashed two Xenons together. One that simply forwards on a single byte to Serial1. The other one echos with the same data expected from the other board I have here.
The conclusion?
It’s still missing a byte here and there. Now I’m thinking it may be some type of USB serial bug whereas something is getting reset before a byte is received/buffered properly.
Do the same test using serial1 and directly connecting the xenon together - this should isolate a few things, your code vs DeviceOS - HUB vs direct connection etc
Have you tried a different HUB and different serial monitor app?
I have now also done some tests for another project and realised that it appears the first byte transfered via Serial1.write(buf, size) seems to have a longer stop byte than all following bytes on Argon 1.4.2
This is the trace of sending four 0x00 bytes with SERIAL_8N1.
Thinking about what you’re seeing more I’m not surprised. When the TX line goes back high, that’s the default state. It may be some delay in moving the next byte from the buffer that’s causing that. If they’re using DMA though, then yes that would definitely be weird and unexpected.
@shanevanj I realized I never replied. I did try two Xenons together and still saw the issue. Curiously I also saw that Serial1.available() seemed to reset after each loop despite not reading from the receive buffer. More deets in the bug report.
I’m going to be looking at it with a pair of fresh eyes this week. The project has to keep rolling!
If it would be consistent between all individual bytes I'd agree but having it confined to only the initial byte I'd see this as potentially problematic tho'
BTW, Gen2 does not behave that way (not tested on Gen1).
Just saw an unexpected issue with the serial1 this am. I have a long term (7day) test running with a serial exchange every 2 mins (structured message with checksum and then a structured checksummed ACK back). This has been okay until now - this morning the serial (USB) and serial1 subsystems are non - responsive.
Argon still alive and publishing to console. Used a remote command to request a status report that would normally print to Serial (USB) and publish same data to console - published data is on console - nothing out of Serial port.
On serial 1 I am using SerialBufferRK and I have a timeout flag displayed on an attached LCD. Timneout was flagged and even when manual triggering the sending system (non Partilce) to send a message - timeout was never reset. External LEDS show messages are being sent from external system.
Restarted Argon remotely from console command and all is working again ..... so this does need some work. @ScruffR gave me an idea and I will attach my logic analyser and take a close look at the serial data flow and timing - something is going on here
)
)
) there’s something funky going on in DeviceOS.