Going crazy with serial communication issue from ThingPlus UCSB-C to Serial MP3 Player

[Gmdesigner]

I have a serial MP3 player that I can get to work from other controllers using Arduino IDE. The serial message it expects to, for example, play the first song on its SD card is:
0x7E, 0xFF, 0x06, 0x03, 0x00, 0x00, 0x01, 0xEF

I’ve been using the code:

#include <HardwareSerial.h>
void setup() {
  Serial.begin(9600);
 Serial1.begin(9600, SERIAL_8N1, 19, 21); //RX21 TX19
  delay(5000);  // wait chip initialization is complete
  
  byte selecttf[] = { 0x7E, 0xFF, 0x06, 0x09, 0x00, 0x00, 0x02, 0xEF };

  Serial1.write(selecttf, sizeof(selecttf)); // select the TF card
delay(2000);
  byte volume[] = { 0x7E, 0xFF, 0x06, 0x06, 0x00, 0x00, 0x1E, 0xEF };

  Serial1.write(volume, sizeof(volume)); //set volume to max
  delay(2000);
}

void loop() {

byte play[] = { 0x7E, 0xFF, 0x06, 0x03, 0x00, 0x00, 0x01, 0xEF }; //// Play first mp3 on card

Serial1.write(play, sizeof(play));
delay(20000);

}

When I try to send it from my ThingPlus USB-C it doesn’t work.
When reading back the serial it was sending it sends most HEX correctly, except that it sends 0xFF as 0xFFFFFFFF and 0xEF as 0xFFFFFFEF

I can’t for the life of me find a way to get the ThingPlus to send the serial message I am coding. Any ideas?

[TS-Russell]

The ThingPlus is expanding some byte values (0xFF and 0xEF) into 32-bit

Try using an explicit cast to force these values to be treated as single bytes when writing to the serial port:

void setup() {
  Serial.begin(9600);
  Serial1.begin(9600, SERIAL_8N1, 19, 21); //RX21 TX19
  delay(5000);  // wait chip initialization is complete
  
  // Using explicit casting to byte
  Serial1.write((byte)0x7E);
  Serial1.write((byte)0xFF);
  Serial1.write((byte)0x06);
  Serial1.write((byte)0x09);
  Serial1.write((byte)0x00);
  Serial1.write((byte)0x00);
  Serial1.write((byte)0x02);
  Serial1.write((byte)0xEF);
  
  delay(2000);
  
  // Volume command with explicit casting
  Serial1.write((byte)0x7E);
  Serial1.write((byte)0xFF);
  Serial1.write((byte)0x06);
  Serial1.write((byte)0x06);
  Serial1.write((byte)0x00);
  Serial1.write((byte)0x00);
  Serial1.write((byte)0x1E);
  Serial1.write((byte)0xEF);
  
  delay(2000);
}

void loop() {
  // Play command with explicit casting
  Serial1.write((byte)0x7E);
  Serial1.write((byte)0xFF);
  Serial1.write((byte)0x06);
  Serial1.write((byte)0x03);
  Serial1.write((byte)0x00);
  Serial1.write((byte)0x00);
  Serial1.write((byte)0x01);
  Serial1.write((byte)0xEF);
  
  delay(20000);
}

Instead of sending an array, this method writes each byte individually with explicit casting to force them to be treated as single bytes. This approach should prevent the expansion to 32-bit values you’re seeing.

If you prefer using arrays for clarity, you could try an alternative approach:

void setup() {
  Serial.begin(9600);
  Serial1.begin(9600, SERIAL_8N1, 19, 21);
  delay(5000);
  
  uint8_t selecttf[] = { 0x7E, 0xFF, 0x06, 0x09, 0x00, 0x00, 0x02, 0xEF };
  for(int i = 0; i < sizeof(selecttf); i++) {
    Serial1.write(selecttf[i]);
  }
  
  delay(2000);
  
  uint8_t volume[] = { 0x7E, 0xFF, 0x06, 0x06, 0x00, 0x00, 0x1E, 0xEF };
  for(int i = 0; i < sizeof(volume); i++) {
    Serial1.write(volume[i]);
  }
  
  delay(2000);
}

void loop() {
  uint8_t play[] = { 0x7E, 0xFF, 0x06, 0x03, 0x00, 0x00, 0x01, 0xEF };
  for(int i = 0; i < sizeof(play); i++) {
    Serial1.write(play[i]);
  }
  
  delay(20000);
}

Using uint8_t instead of byte and writing each byte individually might help avoid the type conversion issue. The key here is to ensure each value is being transmitted as a single byte

I have a few more ideas if either of those don’t get it going

[YellowDog]

@Gmdesigner

When I try to send it from my ThingPlus USB-C

How exactly is everything connected and what specific “Thing Plus” are you using?

Edit:
I was thinking you were connecting the two devices with USB-C and that wouldn’t work

[Gmdesigner]

Thank you for your response @TS-Russell.
I tried this variation and it is still not working. The serial data I am receiving still looks like this:

Received: 0x7E
Received: 0xFFFFFFFF
Received: 0x6
Received: 0x3
Received: 0x0
Received: 0x0
Received: 0x1
Received: 0xFFFFFFEF

I just had someone try the same with another ESP32 board from another manufacturer and they were able to get it to work with the code listed above.

What else could be causing this with the ThingPlus?

Thanks,
Greg

[PaulZC]

Hi Greg (@Gmdesigner ),

I tried your code on a Thing Plus C and it looks fine on the logic analyzer. See below. The only issue I found is that Pin 21 is configured for TX, not Pin 19. The format for Serial1.begin is void begin(unsigned long baud, uint32_t config = SERIAL_8N1, int8_t rxPin = -1, int8_t txPin = -1. I.e. rxPin first, then txPin.

Are you sure the problem is not in your “Received:” print code? It looks like it is printing anything less than 0x7F as 8-bit (unsigned), and anything greater than 0x80 as 32-bit (signed)? Could it be a signed unsigned issue in your print code?

I hope this helps,
Paul

[Gmdesigner]

Thanks @PaulZC I at a total loss.
I have tried several different pin combinations. I had swapped 21 and 19 in that particular code example. I had also tried Serial2 with GPIO16 (RX) and 17 (TX) for example.

Suspect it’s not an error in receiving because the code still does not communicate properly with the serial .MP3 Player.
I can get the serial .MP3 player to work with an Arduino using the same code except swapping for SoftSerial. When I receive that data from that board it appears correct (0xF = 0xF).

As I mentioned above someone else using a different ESP32 board was able to make it work as well.

Now I’m not sure what else to try?

This is for an installation project and I’m running out of time. Any help or ideas are most appreciated.

[TS-Russell]

Until a cause/solution is found I’d recommend using a version that you’ve confirmed works (alternate esp32)

[Gmdesigner]

Thanks @TS-Russell . It’s a pretty disappointing conclusion, but if you all can’t figure out it I don’t think help is coming from anywhere else. This was my first Sparkfun purchase, which I went with to integrate with your DMX shield. I spent a little more to go with Sparkfun for reliability and support, ironically, but have had more luck with the cheap off-brand electronics. I know the solution must be very simple, but I’m out of ideas here.

I appreciate your time and suggestions.

[TS-Russell]

Maybe share a photo of your setup/wiring also…and inspect for any possible solder bridges on the board itself

If all else ends up failing, you can file for a replacement unit/refund here Returns (it’s odd that Paul’s is working fine though)

[PaulZC]

Hi Greg,

I’m sorry. I really can’t work out what’s going on here. And I appreciate you’re running out of time.

I’ve tried selecting a few different boards and board packages to try and replicate your issue, but they all produce clean serial data. I wondered if you were perhaps using the very old “SparkFun ESP32 Boards” (version 1.0.1). But that too produces the correct serial data. All I can suggest is to please check that you have a recent version of the “esp32 by Espressif Systems” board package installed. I am using version 3.1.3, but 3.2.0 is also available. Please also check that you are selecting “ESP32 Arduino \ SparkFun ESP32 Thing Plus C” as the board.

Do you have the Thing Plus C plugged into the DMX Shield when you are running your code?

Best wishes,
Paul

[Gmdesigner]

Thanks @PaulZC this is my first time working with ESP32, so please let me know if you spot anything wrong here:

This is the board I’m using. I just bought it, so i don’t think it is an old model:

This is the board I’ve been selecting in the IDE:

There is also this similar option I have not been using:

Does anything seem out of the ordinary to you?

(oh, and no, the shield is not on, nor any other connections made other than the serial pins I’m trying to get to send correct data on)

Best,
Greg

[Gmdesigner]

Sorry, meant this similar version I have not been using:

[TS-Russell]

Are you getting successful upload msgs?

That’s the correct board selection, although one time I did run into some weirdness using the search feature (like you are); I ended needing to select it manually from the menu options like so

[PaulZC]

Hi Greg,

Thanks for the update. It looks like you have everything configured correctly.

I updated my Windows setup to 3.2.0 and I see the following. The logic analyzer D0 is attached to GPIO 21 and GND. I have Core Debug set to Verbose, which is why there is extra info in the Serial Monitor - confirming the core version.

The output looks fine to me. I will repeat the test on my Mac shortly.

Best,
Paul

[PaulZC]

Same setup on Mac:

So, I’m sorry Greg. I really can’t figure this one out. Everything seems fine to me.

Please share a photo of the wiring between the Thing Plus C and the MP3 player, just in case it provides a clue.

Please also share the code you are using to print the serial data (“Received:”).

As Russell suggested, please confirm that the code upload is successful. Please share a screenshot of the Output. It should include “Writing at 0x… (100%)”, indicating a successful upload. If the upload is failing, the board will keep running whatever code was on there previously.

Best wishes,
Paul

[PaulZC]

Please note that you won’t see the full Verbose Core Debug unless you set the Serial Monitor to 115200 baud. The ESP32 outputs debug at 115200, then your code changes the Serial baud rate to 9600.