Issues with Serial2 in a Photon2 / P2 and ModbusClient library

fishmastaflex · July 10, 2024, 5:35am

I'm having issues interfacing with the ParticleModbusClient RS-485 library here: GitHub - particle-iot/ParticleModbusClient: This is an Particle library for communicating with Modbus servers over RS232/485 (via RTU protocol)

I'm specifically interfacing with Serial2 on my board and am having trouble with messages getting all the way through. It appears to be some timing issue with Serial2.write and Serial2.flush commands.

It seems that the entire full length message is not being transmitted to the RS-485 chip.

See Modbus Slave communication window, which is showing the repetitive polls being different every time.

If I modify the library by adding a delay after the Serial Flush command and it fixes the issue!

MBSerial.flush(); //Wait for transmission to get completed

delay(50);

if (MBUseEnablePin == 1) {  //Switch RS485 driver back to receiving mode.
	setReceiveMode();
}

Here see the RX and TX message being sent back by Modbus Slave program after adding the delay after Flush:

rickkas7 · July 10, 2024, 7:39am

I believe this is an issue on the RTL872x, and affects all serial ports, and also SPI. The problem is that there are two FIFOs, the byte-oriented user FIFO, and also an internal FIFO that is responsible for outputting the actual bits over the wire.

The issue is that the queue will be empty, or the DMA callback is called when the user FIFO is empty, not when all bytes have successfully been transmitted over the wire.

This doesn't matter if all you are doing is refilling the queue. However, if you are using queue empty to change direction in RS485 or de-assert CS in SPI, that will be an issue.

At this time, the only solution is adding a delay.

rickkas7 · July 10, 2024, 8:52am

I'm not 100% sure that is what is happening, however. I ran this test program on a Photon 2 running Device OS 5.8.2:

#include "Particle.h"

SYSTEM_MODE(SEMI_AUTOMATIC);
SYSTEM_THREAD(ENABLED);

SerialLogHandler logHandler(LOG_LEVEL_INFO);

const pin_t signalPin = D2;
const int baudRate = 1200;

const std::chrono::milliseconds testPeriod = 5s;
unsigned long lastTest = 0;

void runTest();

void setup() {
    Serial1.begin(baudRate);

    pinMode(signalPin, OUTPUT);
    digitalWrite(signalPin, LOW);

    Particle.connect();
}

void loop() {
    if (millis() - lastTest >= testPeriod.count()) {
        lastTest = millis();
        runTest();
    }
}

void runTest() {
    digitalWrite(signalPin, HIGH);

    int bufferSize = Serial1.availableForWrite();

    unsigned long start = millis();

    for(int ii = 0; ii < 64; ii++) {
        char c = 0x20 + ii;
        Serial1.write(c);        
    }
    unsigned long writeComplete = millis();

    while(Serial1.availableForWrite() < bufferSize) {
    }

    unsigned long empty = millis();

    digitalWrite(signalPin, LOW);

    Log.info("writeComplete=%lu empty=%lu", writeComplete - start, empty - start);

}

The buffer empty is very close to the end of the transmission, but it does not appear to be before it.

Log messages:

0000310532 [app] INFO: writeComplete=1 empty=532
0000315532 [app] INFO: writeComplete=1 empty=532
0000320533 [app] INFO: writeComplete=2 empty=532
0000325533 [app] INFO: writeComplete=1 empty=533

The statement about the SPI DMA callback is definitely true on the P2/Photon 2/M-SoM but the serial issue could be something else.

rickkas7 · July 10, 2024, 9:03am

It does appear to be a difference in behavior with Serial2.

Since you were using flush() instead of availableForWrite() I changed the code and it looks the same for Serial1:

However this is what it looks like for Serial2 using flush(). The signalPin is deasserted far before the transmission is complete, but only for Serial2.

Here's the Serial2 code (D4 = Serial2 TX, D6 = signalPin):

#include "Particle.h"

SYSTEM_MODE(SEMI_AUTOMATIC);
SYSTEM_THREAD(ENABLED);

SerialLogHandler logHandler(LOG_LEVEL_INFO);

const pin_t signalPin = D6;
const int baudRate = 1200;

const std::chrono::milliseconds testPeriod = 5s;
unsigned long lastTest = 0;

void runTest();

void setup() {
    Serial2.begin(baudRate);

    pinMode(signalPin, OUTPUT);
    digitalWrite(signalPin, LOW);

    Particle.connect();
}

void loop() {
    if (millis() - lastTest >= testPeriod.count()) {
        lastTest = millis();
        runTest();
    }
}

void runTest() {
    digitalWrite(signalPin, HIGH);

    int bufferSize = Serial2.availableForWrite();

    unsigned long start = millis();

    for(int ii = 0; ii < 64; ii++) {
        char c = 0x20 + ii;
        Serial2.write(c);        
    }
    unsigned long writeComplete = millis();

    // while(Serial2.availableForWrite() < bufferSize) {}

    Serial2.flush();

    unsigned long empty = millis();

    digitalWrite(signalPin, LOW);

    Log.info("writeComplete=%lu empty=%lu", writeComplete - start, empty - start);

}

rickkas7 · July 10, 2024, 10:05am

Incidentally, Serial3 also works fine. It's just Serial2.

#include "Particle.h"

SYSTEM_MODE(SEMI_AUTOMATIC);
SYSTEM_THREAD(ENABLED);

SerialLogHandler logHandler(LOG_LEVEL_INFO);

const pin_t signalPin = D6;
const int baudRate = 1200;

const std::chrono::milliseconds testPeriod = 5s;
unsigned long lastTest = 0;

void runTest();

void setup() {
    // Serial3 TX is S0/D15/MOSI
    Serial3.begin(baudRate);

    pinMode(signalPin, OUTPUT);
    digitalWrite(signalPin, LOW);

    Particle.connect();
}

void loop() {
    if (millis() - lastTest >= testPeriod.count()) {
        lastTest = millis();
        runTest();
    }
}

void runTest() {
    digitalWrite(signalPin, HIGH);

    int bufferSize = Serial3.availableForWrite();

    unsigned long start = millis();

    for(int ii = 0; ii < 64; ii++) {
        char c = 0x20 + ii;
        Serial3.write(c);        
    }
    unsigned long writeComplete = millis();

    while(Serial3.availableForWrite() < bufferSize) {}

    // Serial3.flush();

    unsigned long empty = millis();

    digitalWrite(signalPin, LOW);

    Log.info("writeComplete=%lu empty=%lu", writeComplete - start, empty - start);

}

fishmastaflex · July 10, 2024, 2:20pm

Thanks for your in-depth analysis and for confirming my suspicions with logic @rickkas7 .

I've designed two P2 boards that both offer RS-485. One uses Serial3 (no issues) and the other uses Serial2.

If I'm reading your replies correctly, you are suggesting to use availableForWrite() instead of flush() for Serial2? I'll give that a shot and see if I have any issues.

This seems high enough priority (a Serial UART not working as it should) to add to the bug fixes list for future DeviceOS versions. Is it possible to fix Flush in DeviceOS code?

fishmastaflex · July 10, 2024, 2:27pm

Replacing flush() with availableForWrite() is not working unfortunately:

	while(MBSerial.availableForWrite() < ku8MaxBufferSize) {}

	// MBSerial.flush(); //Wait for transmission to get completed
	// delay(50);

rickkas7 · July 10, 2024, 2:30pm

No, availableForWrite behaves the same way as flush() on Serial2.

I believe it's a problem in how Serial2 works on the P2/Photon 2. All of the other ports uses a dedicated UART peripheral, but Serial2 uses the generic high speed serial port, which is also used for SPI. It appears that it behaves differently.

Serial3 shares the same pins as SPI, but Serial3 uses an internal pin mux to switch the port between the dedicated UART peripheral and the SPI peripheral, which is why that behaves differently.

fishmastaflex · July 10, 2024, 3:18pm

Yep, it appears so.

So for now, the fix is to add a delay (not really a solution for my application), change my board design to Serial1 or Serial3, or potentially wait for a DeviceOS solution/fix?

no1089 · July 11, 2024, 3:45pm

Hi Bryan,

We're discussing this with engineering tomorrow during our triage meeting. Will get back to you with feedback once the team have investigated.

no1089 · July 12, 2024, 6:54pm

Engineering is investigating - possibly a quick fix!

fishmastaflex · July 12, 2024, 8:45pm

Excellent - thank you!

fishmastaflex · July 16, 2024, 10:12pm

Hey Chris @no1089 , I assume this is the solution, as noted in the Github Pull Request?:

github.com/particle-iot/device-os

[rtl872x] fixes DMA enabled USART flush

particle-iot:develop ← particle-iot:fix/p2-serial2-flush

opened 02:03AM - 16 Jul 24 UTC

technobly

+12 -2

### Problem - `Serial2.flush()` on `P2/Photon2` does not wait for bytes to be… emptied from USART buffer on D4 (Serial2 TX), but instead when DMA transfer is complete. ### Solution - Enable the IRQ used to signal TX buffer FIFO emptied for DMA enabled USARTs (Serial2 on P2/Photon2), along with a new `busy_` flag, to assist in waiting long enough for all bytes to be transmitted when busy waiting with `Serial2.flush()` ### Steps to Test - Run integration tests `TEST=wiring/no_fixture` - Run fixture test `TEST=wiring/serial_loopback2` (with TX jumpered to RX) - Run example test app while watching the TX pin for each Serial1/2/3 (TX/D4/MOSI) interface and also the signalPin (A0) on Photon2. - Run example test app with Serial1 on M-SoM ensuring the Cellular connection works properly. ### Example App ```c #include "Particle.h" SYSTEM_MODE(SEMI_AUTOMATIC); SYSTEM_THREAD(ENABLED); SerialLogHandler logHandler(LOG_LEVEL_INFO); // Try them all, signalPin should not go LOW before all bytes are flush()'d // #define MY_SERIAL Serial1 #define MY_SERIAL Serial2 // #define MY_SERIAL Serial3 // P2/Photon2 // TX = Serial1 TX // D4 = Serial2 TX // MOSI = Serial3 TX const pin_t signalPin = A0; const int baudRate = 600; auto TEST_PERIOD_MS = 5000; auto lastTest = 0; void runTest(); void setup() { pinMode(signalPin, OUTPUT); digitalWrite(signalPin, LOW); Particle.connect(); waitFor(Particle.connected, 60000); MY_SERIAL.begin(baudRate); } void loop() { if (millis() - lastTest >= TEST_PERIOD_MS) { lastTest = millis(); runTest(); } } void runTest() { digitalWrite(signalPin, HIGH); int bufferSize = MY_SERIAL.availableForWrite(); auto start = millis(); for (int ii = 0; ii < 64; ii++) { char c = 0x20 + ii; MY_SERIAL.write(c); } auto writeComplete = millis(); MY_SERIAL.flush(); auto empty = millis(); digitalWrite(signalPin, LOW); Log.info("bufferSize=%d writeComplete=%lu empty=%lu", bufferSize, writeComplete - start, empty - start); } ``` ### References - https://community.particle.io/t/issues-with-serial2-in-a-photon2-p2-and-modbusclient-library/67177/4 --- ### Completeness - [x] User is totes amazing for contributing! - [x] Contributor has signed CLA ([Info here](https://github.com/spark/firmware/blob/develop/CONTRIBUTING.md)) - [x] Problem and Solution clearly stated - [x] Run unit/integration/application tests on device - [x] (N/A) Added documentation - [ ] Added to CHANGELOG.md after merging (add links to docs and issues)

jalbersr · July 18, 2024, 7:28pm

Hi, @fishmastaflex!

Yes, the issue was found and a fix will be implemented in the next release.

gusgonnet · July 19, 2024, 8:26pm

I know I shouldn't be asking this, but here it goes: is there an ETA for the next release?
Thanks

fishmastaflex · August 22, 2024, 4:53pm

I see that Pull Request #2800 is in Develop now and is now a milestone for the next version 5.9.0.

Anyone have any idea when 5.9.0 will be released to finally test this fix?

Topic		Replies	Views
Modbus support, hardware + libs, production solution Hardware	11	1853	July 29, 2018
RS485 sensor communication connection General	10	7403	September 30, 2017
RS-485 and MODBUS Master Firmware	1	64	July 1, 2024
Particle Modbus Client Firmware	4	97	April 25, 2024
Particle ModbusMaster Library with two slaves Libraries	1	1162	January 3, 2019

Issues with Serial2 in a Photon2 / P2 and ModbusClient library

Related topics