Boron Serial1 problems

Troubleshooting
1

Hello,
TL;DR -> I’m using a 3rd party serial device on Photon and Boron. Photon works great, Boron does not under the exact same configuration.

Here’s the tale of woe:

I’m having serial communication issues with an app we’ve programmed. It connects to a proprietary RF communication adapter at 115200 baud and reads data through Serial1. Data is received by sending hex commands to the device and reading the response. The device works perfectly on the photon without issues.

On Boron it does not work, and I have extensively investigated the issues. I attached an Arduino Mega to spy on the data being written. The Boron and Photon write identical data to the device TX lines with nothing attached, and I confirmed this using the Arduino. Loopback works as expected on both devices as well. Once I attach the serial RF device Boron stops writing data correctly. Photon is fine. Readable hex data keeps being written, but as soon as the Boron is connected to the device the hex data changes to the wrong values. I have all the ground, power, and data lines connected correctly, and there’s plenty of current available.

Here’s an example of what I am seeing:

Data that should be written, and is written by the Photon, and read by the device and Arduino:

[C5, 7, 0, 21] (startup command, consistent every write)

But on Boron, what I read with Arduino when the RF device is connected:
[FE, 8, 0, 23]

and another:

[FE, 8, 23, 3]

and again:

[FE, FE, 8, 23]

as soon as I disconnect the device TX line from the Boron, the data returns to normal. I have not yet hooked up my o-scope to look at the waveform, but I’m not sure what I’ll find there. Also, I’m unfortunately stuck with 115200 baud so if it’s a baud rate / data corruption issue I’m stuck there. Help!?!

2

There is one big differerence between the Boron and the Photon.
While the Photon can accept 5V on the RX line the Boron can’t since the nRF52840 has not 5V tolerant pins while the STM32 used on the Photon has very few non-5V-tolerant pins.

So make sure you are not exceeding the limit on the Boron.

Also, what device OS version are you running?
There was this issue with older versions

3

Thank you very much for the response. I’m familiar with the 3.3V vs. 5V, the voltages are 3.3V, I’ve made sure of that, and it’s not the RX I’m having trouble with, it’s TX.

Regarding the OS version, It’s running the 1.1.0 device OS. Should I try one of the release candidates?

4

Yes, the issue I linked above was closed on May 16th via a fix (that should address other serial issues too) slated for 1.2.0-rc.1 but it's always best to try the latest as it may include even more fixes.

5

I think I’ve found the issue. Using the buffered serial write seemed to clear it all up:

Serial1.write(buf, len);

I was using a for loop to write to the device, worked fine on photon, but for whatever reason the serial on boron is much more reliable using the buffered serial write. What a frustrating problem, but glad to find a solution!

1 Like
6

I’m having similar issues on the same devices.

Any changes on your end with this or did you juat leave it?

7

Good Afternoon,

I am having similar issues with the B-series (B402) with serial1 writing.
I am working on communication with an external CPU. Data exchange upon request

I can read the data from the CLI when the serial write is initiated externally,
But serial1.print & serial1.write are not working.

  • firmware has been updated to the latest version,
  • I am including the code we are using on the B-series

Everything you can do to help us would be great.

on Boron:

// This #include statement was automatically added by the Particle IDE.
#include <SparkJson.h>


long int post = 30000;

long int now = 0;

long int time_now ;

char jsonChar [100];

void setup(){
 Serial.begin(115200);    
 Serial1.begin(115200);   
    
}
void loop(){
    
    time_now = millis();
    if(time_now-now>post){
        
        now = time_now;
      tokenizer();
    
    }
    
    if(Serial1.available()>0){
      
        char readd = Serial1.read();
        Serial.print(readd);
        
        
        }
    
}


void tokenizer(){
   
    StaticJsonBuffer<200> jsonBuffer;

  JsonObject& root = jsonBuffer.createObject();
  root["Boron"] = "send";
  root.printTo((char *)jsonChar,17);
  delay(10);
  while(Serial1.availableForWrite() > 0){
  Serial1.print(jsonChar);
  }
  Serial.write((uint8_t*)jsonChar,16);
  Serial1.write((uint8_t*)jsonChar,16);
  
}
8

I can’t quite follow the reasoning for exhausting the TX buffer completely first :confused:
Can you elaborate?

9

@ScruffR
thank you so much for your response.

I found this trace from other lines of code from similar projects.
I am not 100% sure I understand the comment about exhausting the buffer.
I am trying to initiate the request for data to the external CPU.
Should I follow a different approach? Is there a better syntax that I can use to call for the serial1.write on B402?

Thank you,

10

This loop will make sure the TX buffer will be filled to the brim.
So when your code falls out that loop there will be absolutely now free space in the TX buffer to add hence the next Serial1.write() will block till there will be room to add the next byte.

11

Please note that as I am helping Mariconda… even the simple program such as…

void loop(){
Serial1.print(buff);
or
Serial1.write(buff);
is not emitting the data.
however Serial.print and serial.write are working fine.

Please help what is the matter with Serial1 ??

12

I have tested the functionality myself and cannot reproduce the issue.
I tried with a simple loop-back to read back on the device what it itself sends and that worked as expected

char   msg[256] = "not set yet";

void setup() {
  Serial1.begin(115200);
  Particle.variable("msg", msg);
  Particle.function("serTest", serTest);
}

int serTest(const char* arg) {
  char c;
  int  i = 0;
  memset(msg, 0, sizeof(msg));                                              // clear string buffer
  while(Serial1.read() >= 0);                                               // flush RX buffer
  Serial1.write((uint8_t*)arg, constrain(strlen(arg), 0, sizeof(msg)-1));   // write out incoming string
  delay(50);                                                                // wait for it to happen
  Serial1.readBytes(msg, strlen(arg));                                      // read back data
  return strlen(msg);                                                       // tell us how much was read
}
13
  1. do you have a picture of how your device is wired up? You definitely want to eliminate any hardware issues you might have.
  2. @gmariconda, what do you mean by “not working”? No output? Garbage output?
  3. you probably want to add some print or debugging statements in your code to see where things are getting stuck. Is data actually every getting printed to Serial1, or are you accidently skipping steps due to your conditional logic?
  4. Try to make a test program where you just print continuously to Serial1. Get yourself a 3.3v FTDI, hook it up to a serial monitor on your PC, and run a simple while(true) {Serial1.print("Stuff"); delay(1000);}
  5. do you have an oscilloscope? Does your code work on any other arduino devices?
14

@aklein24, I guess you didn’t intend to reply to my post but rather to the thread or someone who does experience that issue, right?

1 Like
15

You’re correct, my bad.

16

@ee.ahmad Please see my comments below:

17

Hi sir, we are connecting boron to STM32F4 mcu… we are receiving the bytes from the MCU. means that MCU is sending data and SERIAL1.read() is doing its job. however Serial1.print(xxx) or Serial1.write(xxx) is not doing the job.

Both Rx and Tx are also pull up to 3.3V with 10K resistor which i think might not be an issue for boron. this is did just to keep them high to avoid any noise on channel during idle state.

18

That info helps. Have you tried it without the input pullup on the Tx line? I don’t think you need that pullup, and it could be affecting it. I think to know for sure you’re going to need an oscilloscope, scope the Boron Tx line and see what you get. I’d scope the output without it connected to the STM32 to start, and if you get what you expect then connect the STM32.

Also, side note, are you sure the STM32 is reading the Boron Tx line correctly? Regardless, the oscilloscope will tell you what is going and will allow us to advise on your next steps.

1 Like
19

As my own tests (with code above) clearly show it's not an inherent fault with Serial1.print() or Serial1.write() they do work in loop-back and also between two Particle devices (no extra pull-resistors on either RX nor TX) hence I'd second @aklein24's assertion that it may rather be caused by your external circuitry.