Arduino Due Not Problem using 230400 Baudrate

Hi All,

Once again back for some help! I did post a topic the other week, where I am trying to communicate with an automotive ECU to pull real time data from it. I have the spec sheet and the ECU uses an RS232 lead and a baudrate of 230400. The ECU also works on request response, so you must send it a command, and then it will reply. If you send the wrong command, or use the wrong baudrate you will not get a response.

I have been using an Arduino UNO, and softwareSerial to communicate with the ECU, and I could send a request and get a response back. The problem I had is the response was incorrect in terms of format and content. I tried a few things, and the payload that appeared in the serial monitor was always incorrect. However I could use a USB/TTL adapter,connected to the MAX232 adapter im using, along with a PC comm port tool, and I could send the same command as Im sending in the Arduino code and get a valid response.

So the only thing left to try was a more capable board in terms of clock speed...

Based on this I bought an Arduino Due. and modified the code slightly, so instead of the MAX232 being used by softwareSerial its connected to Serial1 , pins 18 and 19.

Now, I see the transmission of the message, but I get no response. I tried the same test with the USB/TTL adapter and that still works fine. I also tried a loop back test by bridging pins 2 and 3 in the MAX232 and I can see the transmitted message come back and display in the serialMonitor.

So given that the :

  1. Request is correct,
  2. I'm using the same MAX232 adapter as with the UNO and with the direct to PC test which both get responses from the ECU.
  3. I'm using the same code just modified to set the MAX232 to the available Serial1 connections.
  4. The baudrate of 230400 when used on the UNO and the PC com port tool gets a response

The only thing I can think of, is that when Im setting the baudrate for Serial1 to 230400 on the Due somehow its not? No idea if thats possible! I have tried 250000 and 115200 just to check and again, I can see the response sent but the ECU does not respond.

One other thing that maybe relevant - I was unable to download the 'Arduino SAM (32-bits ARM Cortex M3)' I suspect as Im on a managed laptop. I was unable though to download 'Arduino SAM (32-bits ARM Cortex M3) with ARM64 support' which allowed me to select the board in the IDE. Im assuming this isnt causing this issue but should be noted.

Does anyone have any thoughts? The code Im using is below:

//#include <SoftwareSerial.h>
//#include <AltSoftSerial.h>

#define DEBUG                             (1)

/**************************************************/
/*      ECU Comms                                 */
/**************************************************/
#define MIN_FRAME_LEN                     (10)
#define MAX_FRAME_LEN                     (768)
#define SYNC_CH_0                         ('M')
#define SYNC_CH_1                         ('E')

#define MSG_TYPE_REQ                      (0x0)
#define MSG_TYPE_RSP                      (0xF)

#define CLASS_ID_REPORT                   (0x0)

#define MSG_ID_REPORT                     (0x0)
#define MSG_ID_ACK                        (0x1)
#define MSG_ID_SET_STATE                  (0x2)

byte rx_buf[MAX_FRAME_LEN];
int rx_idx;
unsigned int rx_frame_len;

struct proto_frame {
  byte sync_ch[2];
  unsigned int len;
  byte type;
  byte class_id;
  byte msg_id;
};


//##### Removed as using Due hardware pins 18, 19
//SoftwareSerial Serial2 (8, 9); //232_TX,232_RX // Config to assign Digital io ports for the RS232 Shield

struct proto_frame rx_frame;

/* This is to create and send a request to the Me221, in order to get a response back. This will be sent once,
  and for persistent comms need to introduce a cyclical Ack sent every 1s*/
void start_reporting_req() {
  byte req [] = { 0x4D, 0x45, 0x01, 0x00, 0x00, 0x00, 0x02, 0x01, 0x03, 0x05,   };

  Serial.print("Sending: ");
  Serial1.write(req, sizeof(req));
  Serial.println();
}


void setup() {
  /* Init debug serial for serial monitor*/
  Serial1.begin(230400);
  Serial.begin(9600);

  Serial.println();
  Serial.println("Serial debug line open");

  /* Init ECU comms - check baudRate, its dependant on Me221 FW version:
    115200 baud rate (for versions <2.1.2.)
    230400 baud rate (for versions >=2.1.2)  */

  rx_idx = 0;
  delay(2000);
  Serial.println("Initialized software serial");
  start_reporting_req();
}

/* Main loop that handles the buffered response byte by byte and checks for sync bytes (M E) to signify the start of the frame.
  If successful message received, its sent for processing*/

void loop() {
  while (Serial1.available()) {
    rx_buf[rx_idx++] = Serial1.read();

  }


  for (int i = 0; i < (rx_idx); i++) {

#if (DEBUG == 1)
    Serial.print(rx_buf[i], HEX);
    Serial.print(" ");
#endif

  }

  Serial.println("\n");
}

the DUE uses 3.3V logic - did you use a level converter on the RS232 Tx to Due Rx
how did you power the MAX232

Hi,

So for powering the max232, i used VIN pin and ground. Incidentally, when I wired the USB/ttl adapter to the MAX232, i used the due to power the MAX232 and used the same pins, and it worked fine.

I have also successfully used the 3.3v pins to power the MAX233 on my UNO, and ive also tried it on the DUE but I saw no change in results.

Perhaps using a level converter to get true 5v is the next thing to try though?

Kind Regards

Joe

MAX3232 works @3,3V.

1 Like

Another potential cause for the issue could be the tolerance of the baudrate. Do you have an oscilloscope where you can measure the actual baudrate of the ECU and compare that with the actual baudrate of the Due? On my Due the baudrate is of by +3.6% at 230,400.
Depended on the ECU the overall error could be smaller or bigger.

The SAM3X datasheet has an example table in the USART section that may be helpful in understanding the issue.

running your program of post # 1 on An Arduino Due connected to a RS232 shield connected to the RS232 COM1 port of a PC
ReadTerm displays (which is correct)
image

if I connect the RS232 shield VCC to the Arduino Due 3.3V - a scope displays the Due Tx signal
image
you can see the RS232 voltage range is -6 to 5.5V which is too low for many RS232 devices

if I connect to RS232 shield VCC to 5.0Volts the scope displays the Due Tx signal
image
voltage range is now -8 to +8 which is still a bit low

try connecting the MAX232 VCC to 5V but also have a voltage divider on the RS232 Tx to Due Rx line
or better still use a Mega which use 5V logic and also has hardware serial ports

Hi @horace - thank you for your going to the trouble to recreate this, i really appreciate it. I will definitely need to try running the MAX232 at 5v. However the one thing that makes me think 3.3v should be ok, is the fact that I have used the DUE provided 3.3v successfully when connecting the MAX232 directly to tx and rx of a Usb/ttl converter.

@Klaus_K thank you also for your thoughts, i must admit this was my initial thought - that somehow the baudrate is ‘off’ when using the DUE, so although I think Im using 230400, whats actually transmitted to the ECU is different. If thats the case though it seems difficult to know what value to enter in!

Kind regards

Joe

it can depend upon how sensitive the RS232 receiver is to high/low voltage levels, slew rates, baudrates, etc - the faster the baudrate the more likly you are to have problems

The values are computed by the library code. The baudrate differences comes from the fact that the oscillator frequency can only be divided in fixed steps. When you can chose the baudrate you can select one that can be created from both systems oscillators with a smaller error. In your case you do not have the option.
If it is the cause of the issue and you really need this working you could change the crystal on your Due. That would likely affect other systems e.g. USB communications.

Hi @horace and @Klaus_K ,

Thanks again for the suggestions. Since my last update i have been back over and checked everything. It turns out the MAX232 i though i had was in fact a MAX3232, so should be fine at 3.3v. Nonetheless I did some back to back tests using 5v and 3.3v and in summary:

  1. The ECU responds to the UNO when using the MAX3232 at 5 or 3.3v @230400 (albeit the payload passed into the serial monitor is illogical).

  2. The ECU responds to the PC com port tool when the MAX3232 is connected directly to a USB/ttl adapter, and using either 5 or 3.3v, with the baud rate set at 230400 (this also yields a valid payload in the pc com port tool monitor)

So once again I find myself looking at the choice of board! Ive ordered a teensy 4.1 to try, i can make use of it if this doesnt work so its not a complete waste.

Based on the above though if you have any more thoughts feel free to share them. I’ll update tthe thread when uve tried with the teensy board anyway,

Kind regards

Joe

Hi All,

Just to add some closure to this, I have received the teensy 4.1 board, and ran the exact code from my first post, using the same MAX3232. The MAX3232 is connected the teensy 4.1 3.v supply, and I'm using hardwareserial pins 0 and 1. The baud rate specified for serial1 is still 230400..

I can confirm I am now getting the exact results that I expect! So it would seem this is certainly baudrate related, and the teensy in this instance is better able to transmits at exactly the correct rate than both UNO and DUE.

Thanks again everyone for the help and advice,

Kind Regards

Joe

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.