MIDI-library works on Minima but not on WIFI

Hardware UNO R4 UNO R4 WiFi
1

While the Basic IO example from the FortySevenEffects MIDI library will work on the Minima, when trying it on the WIFI it causes the system to crash and the board will no longer be able to upload anything, even the blink example, citing that:-
No device found on cu.usbmodemDC5475C45C282
Getting it back to work involves a lot of messing about that I have still not nailed down to a specific procedure.

I am using IDE 1.8.19 on a Mac.

Both Uno R4 boards work when you send MIDI "by hand", that is writing at MIDI baud rates to the appropriate port using Serial.write.

I am assuming that there is something about the WIFI that the serial.begin doesn't like. I have studied the source code of the library and the documentation, but I can't seem to find anything.

I do appreciate that this might be a problem with the MIDI library I, so I posted the question on their GitHub discussion pages, but thought I would ask here as well in case it was a problem with the board's libraries. I am running the latest 1.0.4 R4 board installation.

Thank you for reading.

2

I suspect the issue is in the serialMidi.h and the constructor of the transport. Now the details of the ESP powered UNO and the pin assignment in particular, i don't want to dive into, since the Arduino team made some decisions that, well complicate things particular when using libraries which do support ESP32 boards.
I would recommend you to comment the

mSerial.begin(Settings::BaudRate);

out of the this section or add a compiler directive to skip this part in case of an ESP32 architecture, and call
Serial.begin(BAUD, FORMAT, RX_PIN, TX_PIN); from your sketch before you call MIDI.begin();
That way you control which pins are assigned as RX & TX, and when MIDI.begin() is called, these assignments are not reverted back to their defaults.

Hmm yeah, i would go for the old-fashioned, hold the reset button until compilation is complete, but i can't help you much further than that.

As stated i suspect that the issue is caused by the use of Serial pins which are also connected to Flash or other peripherals.

Other option would be to try and upload the sketch using the standard ESP32 core, but then the whole pinout configuration is different, and also the modification i suggested earlier would still be a good idea.

3

If you double tap the reset button, it will put you in the ESP32 bootloader and hold there for you to upload new code.

1 Like
4

It makes no deference, it is not the cure once the board is in a non uploading state. I have tried this and it is not the thing that makes it recover.

All that happens is that the built in LED dims up and down and the code never gets to connect / reconnect because it doesn't get past the:-

Error.

5

Can you upload through the ICSP headers ?
I mean, since USB is included in the ESP32-S3, there is no way to circumvent the issue otherwise.
Really some of the Arduino team should come to the rescue

6

Thanks for your comments.

What in the MIDI library?

The documentation points to the hairless page where the baud rate is changed after the serial begin. Anyway the compiler will not get past the FORMAT parameter 'SERIAL_8N1' and '8N1' both fail.

I must add that at no time have I ever downloaded or activated any ESP32 code.

7

For you always.

Yes in the midi library, this part actually looks identical to the standard included MIDI.h from the IDE

You may need to scroll down a bit till you get to the implementation of begin() at line 56.

Hmm well in that case i will need to have a look at the core files that those people from the Arduino team have created to see what they did with hardwareSerial.h
in the latest ESP32 core (2.0.11) begin() is declared as follows

void begin(unsigned long baud, uint32_t config=SERIAL_8N1, int8_t rxPin=-1, int8_t txPin=-1, bool invert=false, unsigned long timeout_ms = 20000UL, uint8_t rxfifo_full_thrhd = 112);

huh, i only now see the combination unsigned long & uint32_t ah well different code writers.

Well the processor on your board is an ESP32-S3 though, and you should be able to upload sketches using the esp32 core, and i have seen thread from people who have doen this, but somehow the Arduino team have changed the pinmap names for GPIO pins to make them compatible with the AVR-UNO pinmap, which means that if you upload code using espressifs esp32 core, your whole pinmap does not correspond with whatever is on the silk of the PCB, to make matter worse, they have not done this in a way that it is done on a nodeMCU, but rather D2 = 2. I did see a pinout image with reference to the actual ESP pins in another thread, but i don't know where that went.

Point is that almost all ESP32-S3 compatible libraries will work on this board, but with different pin names, whereas a lot of libraries will not work with what they've have done.

I'm gonna have another look through my activities to see if i can find the pinout diagram.

8

Ah yeah now i remember that was a Nano ESP32, not quite the same thing.

9

On the U4 an ESP32-S3 is a processor that is on board but it is not the only processor, the main processor is accordingto the documentation is the

R7FA4M1AB3CFM#AA0, often referred to as RA4M1 in this datasheet, is the main MCU on the UNO R4 WiFi, connected to all pin headers on the board as well as all communication buses.

@Delta_G
Anyway my issue with getting the board back to a loadable state has been solved this afternoon.

It is simple but took a lot of tracking down. I remove the USB cable from the board and plug it back in. Then I load a known good piece of code like one of the LED matrix demonstrations, and I am back in business until it breaks again.

10

I have a thread open on the R4WiFi board about using it as a host controller. We found the lines that switch the USB connector from the ESP-32 to the RA4M1. That sounds like what is happening and then it can't upload because the bootloader on the ESP is not connected to the USB connector anymore.

For me I do the double tap and then plug in the USB cable and it goes back to being recognized as the ESP-32.

11

Well this complicates things, why is there even a need for that one ? The s3 has native USB and is rather quick.

So i don't know what you are actually trying to do, but eh, if it's midi, you want UARTs, and in that case just an ordinary ESP32 Wrover devkit may be a much easier solution (cheaper too !) 3 hwUARTs with freedom to assign custom pins for Rx & Tx. I built a triple midi-merger out of it. They do lack native USB though, but apparently there is a way, though i haven't tried it yet.

12

Could you actually test and see if that mSerial.begin() statement is the cause of the crash, or rule it out as a cause, i would like to know.

13

In order to make all relevant information available to any who are interested in this subject, I'll share a link to that related discussion here:

14

Thanks, although there has been no response so far.

So what I am actually trying to do is to get the FortySevenEffects MIDI-Library working on the R4 Uno Minima & WIFI boards. I am not interested in other ways to generate MIDI on these boards, I can do that already.

I am not particularly interested in the ESP32 chip in the WIFI board, if you look at the schematic you will see very few of the pins on that chip are actually accessible, and most of those that are, are only brought out to tiny solder pads next to the board.

I am starting with the basic IO example from the libraries example folder. I have modified this to work with the Minia board. This just involves adding the baud rate declaration to the example so that it works with the 'hairless' helper application running on your computer. This only works on older Mac OS, the latest one where it works is macOS Mojave V 10.14.6, but I understand that it works on PCs and Linux.

However, when I run the same code on a WIFI board, it breaks the board and will no longer be programmable. So as the first step in my project I am trying to see what changes I have to make that are different to the changes I made to make the library work on the Minima.

I hope you now understand what Iam trying to do.

At this stage of the game I am reluctant to make any changes to the library itself as I prefer to let that come from the FortySevenEffects side. Also, as I said it works on the Minima, so I feel it is not a fault with the library, but something different about the WIFI board.

Thanks, but the double tap puts the R4 into the search for a serial port mode. When I "brake" a board it has already been put into this mode by the start of the download process, but the process bails out before it attempts to do a download. So I guess it is a different fault.

15

On the WiFi it puts the ESP32 into the search for serial port mode and connects it to the USB connector. At that point, and under most normal circumstances the R4 is not connected to the USB connector.

If you solder the pads on the back or set pin 21 as OUTPUT and HIGH then it will connect the USB connector to the R4. Until then the R4 has to talk through the ESP32 much in the way that the 328P used to have to talk through the 16U2 on the UNO-R3.
(This is contrary to the datasheet for the R4 which says pin 40. Datasheet is wrong from what I can tell from my tests)

But this all sounds like it has nothing to do with your issue. If you're wanting code to work the way it does on an old UNO then you want it to go through the ESP32 as a serial to USB adapter. That's the default state of the R4WiFi board.

Must be something else breaking the Midi code. Sorry for the red herring.

16

I understand your reluctance, i would do some testing myself, but i don't have one of those boards. I am naturally curious on this matter and always keen to investigate as deep as i can. The minima doesn't have an ESP32 on there, and i have had experience with ESP32's where the starting of the UART on particular pins can cause the ESP to crash (particularly if these pins are also connected to the Flash). Since most midi libraries (actually all of them i think) use the UART(s) and most of them few to none of the other peripherals, i would look there for the cause first, to exclude it or confirm it.

Library authors would have to purchase a board (i saw some of them are sold out) to do the same testing that you can do. The Arduino team has expressed that they will help library authors to solve compatibility issues, but all of this will take time and effort, so i guess patience is required.
I am always grateful that people let met use their code free of charge, but to curious to completely stay out of their finished product.

A thought popped into my head just now, does the normal MIDI.h (IDE built-in) library work without issue or does the same thing happen ?

17

I did try that so my setup function is:-

void setup()
{   
    pinMode(LED_BUILTIN, OUTPUT);
    // correction for WIFI board
    pinMode(21, OUTPUT);
    digitalWrite(21, HIGH);
    MIDI.begin(4);                      // Launch MIDI and listen to channel 4
    Serial.begin(115200); // HAIRLESS DEFAULT SPEED
}

At first there was delight in that it didn't break my board. It didn't work either. Then I discovered that on subsequent downloads I was back to the error about the serial port. Then the recovery process required was the double click like you said. However while this resulted in being able to down load, the WIFI's serial port had vanished, so I couldn't connect hairless to it.

So this might be part of the problem or as you say a red herring. Or perhaps a herring of a different colour?

18

Well I think I have cracked it. Reading the latest on line cheat sheet I notice that it recommends using pin 40 to the connected to the USB Serial port on the RA4M1. This worked but again like using pin 21 subsequent downloads failed.

EDIT :- in the light of the comments below I have changed my answer here. Pin 21is the correct one to use. However, if the select line is left high then it requires a double click on the reset to get it to load again. Where as, if it is left low then a power cycle will reset the board.

However, the reset procedure for the board was to unplug and reconnect the board from the computer's USB. This then set the WIFI board ready to receive a new download.

Shades here of the Raspberry Pico 2040 when you use one way to program it in C. What I did in that case was to make a small board that contained a slide switch to allow the power from the computer's USB to be removed and reconnected. Thus not necessitating plugging an unplugging of connectors and so avoiding excessive plug / socket wear.

So I dragged out this switch and used it on the WIFI board and it was successful in resetting the board for a new download.

I believe there is a link on the back of the WIFI board that might do the same thing. The cheat sheet says:-

On the back of the UNO R4 WiFi you will find solder pads labelled "RA4M1 USB". If you create a short circuit between these pads, by for example creating a bridge across them with solder, the RA4M1 will be connected to the USB Serial port, instead of the ESP32.

But I prefer not to do this as it reduces the flexibility of the board. It will probably be great for using the WIFI in a dedicated application.

So this is the setup function which makes the Basic IO application work.

void setup()
{   
    pinMode(LED_BUILTIN, OUTPUT);
    /* correction for WIFI board to switch the USB back to the RA4M1
       this also requires resetting the WIFI board by unplugging and replugging
       the board from the USB, or cycling the power from it
    */ 
    pinMode(21, OUTPUT);
    digitalWrite(21, LOW);
    MIDI.begin(4);                      // Launch MIDI and listen to channel 4
    Serial.begin(115200); // HAIRLESS DEFAULT SPEED
}

If you are interested in making your own power switch, here is the layout of how to wire it up on strip board, along with some pictures of how it looks.

Front
Front1000×839 162 KB

Back
Back1000×738 209 KB

In use
In use1000×750 156 KB

USB-off
USB-off1000×472 147 KB

2 Likes
19

I wonder if they have 40 and 21 mapped to the same pin.

20

If they did then using 21 should work, but it didn't, the board recovery using pin 21 was the double reset click like you said not the remove power like I found. With the double reset click I 'lost' the serial port.