Problems with DREQ on GPIO0/D3 and Booting

[jaketeater]

While I have ESP8266 (WEMOS D1 mini pro)/VS1053 radios that work with this library immediately when powered, I have some radios that do not boot unless I press the ESP8266's reset button after power on.

If I rewire it, and connect GPIO0/D3 to 3.3v, the radio boots fine (but there is garbling, I assume because the 1053 appears to be signaling it's ready).

Has anyone encountered a problem like this? Any help would be appreciated!

Here's some more info I've gathered after doing some searching:

From what I can tell, if GPIO0/D3 is low on boot (power on) the ESP8266 goes into Uart Bootloader instead of the boot sketch - which is the desired result.
https://github.com/reaper7/Arduino_ESP8266_SDK1.3/blob/master/doc/boards.md#boot-messages-and-modes

GPIO0/D3 needs to be high, but the 1053 does not raise it until the 1053 is ready. (https://www.sparkfun.com/datasheets/Components/SMD/vs1053.pdf page 48 "After a hardware reset (or at power-up) DREQ will stay down for around 22000 clock cycles")

When pressing the reset button on the 8266, it does not check the GPIO pins and boots the sketch, which (I am guessing) is why I am able to get it to work after pressing the reset button.

But why is this not consistent across the other radios I've made?

[Dr-Dawg]

I have two hints later on, but first

• the radios that do not boot properly, are WEMOS D1 Mini Pros, too?
• are you using your own sketch or have you tested the webradio example?
• Is there any output on a serial monitor?
• I hope the VS10xx'S DREQ pin is disconnected when you connect D3 to 3.3V ? Because with a connection, the VS10xx setting DREQ to ground and D3 being at 3.3 V sounds like hardware damage to me. I assume the garbling you hear is sending data to the VS10xx even when its buffer is full and it sets DREQ to low.

Some simalar problems that occured to me (Arduino IDE and ESP32):

• First guess Serial communication: using my own sketch, I created a lot of data load on the serial connection using print Serial.print commads. This worked fine when connected to PC, the radio could "talk" to the Arduino IDE's serial monitor. However, connected to an USB loader sometimes the radio refused to work. The solution was to define a flag like

bool DEBUG_SRL = false;

in the beginning and replacing the Serial.print commads with something like

 if(DEBUG_SRL)
    Serial.println(var);

So, for testing and programming purposes, the flag is set to true and for the final version it is set to false.

• Second guess: DREQ Pin - you say that D3 is low on boot? If it stays low, this would cause an infinite loop in the player.begin(); statement, when calling await_data_request:

    inline void await_data_request() const {
        while (!digitalRead(dreq_pin)) {
            yield();                        // Very short delay
        }
    }

Instead of rewiring I would try to comment the await_data_request() function within the player.begin() part in VS1053.cpp and see whether this works.

Something like this happened to me a few times (not reproducable) after loading the MIDI plugin on VS1003 boards. Btw, which VS10xx board do you use? I remember that some boards start in MIDI mode, which is the reason for the player.switchToMp3Mode(); in the demo. Maybe placing this statement before the player.begin could help?

I hope, some of the provided ideas turn out to be helpfull :-)

[jaketeater]

thanks for the quick reply! - just wanted to let you know that I read this right after you sent it, but I'm busy at the moment so it will be a few days before I am able to get back to the project, and then post an actual reply.

I'm just leaving this comment for now as I don't want the lack of reply to be misunderstood - I am very interested in what you said and will be trying it out and posting a reply here once I do. Thanks again!

[jaketeater]

I was finally able to make time to look at this again.

tl;dr - I had two radios that did this (and many others that did not), after replacing the VS1053 boards with a new ones, the problem was resolved in both - the Wemos D1 Mini Pros were able to boot up. My guess is there was some sort of defect in those two VS1053s that caused the GPIO0 to be 0V when the ESP8266 booted.

I will add a few more details in case others experience similar problems. I will also hold on to one of the defective VS1053s

This chart (from here) shows how to configure how the ESP8266 boots. With GPIO0 high, it will load a sketch, with it low, it uses the Uart Bootloader. When it boots, it gives a boot mode message, I was getting the message that corresponds with the 0v 0v 3v, not the desired 0v 3v 3v.

GPIO15	GPIO0	GPIO2	Mode
0V	0V	3.3V	Uart Bootloader
0V	3.3V	3.3V	Boot sketch (SPI flash)
3.3V	x	x	SDIO mode (not used for Arduino)

Because it was booting to Uart Bootloader, it wouldn't execute the sketch.

The boot behavior is different when the reset button is pressed - and it will boot the sketch independent of the state of the pins in the chart.

As far as why those two VS1053s held GPIO0 low, I am not sure. It's possible they came that way, or perhaps I damaged them.

For my project, I made a PCB to connect the Wemos D1 Mini Pro to the VS1053 as well as an amplifier IC. So the wiring wouldn't have changed between the working units and the faulty units.

I am making radios for elderly people from my church. We have an internet radio station that carries services live and plays music as well. The radios I make have only a volume knob for an interface. When the volume is low, the radio stops streaming. When the volume is turned up, the radio begins streaming.

This has been very helpful during the last couple of years, as the project has evolved.

I intend to get the project on github soon

Anyway, thank you for all your work, and your help here.