Runs immediately on upload or reset but not from battery

The code below is intended to play all tracks using a DFRobot MP3 Player. It starts immediately after a compile upload or using the UNO button reset. But I want to use a battery power supply in the project. Disappointingly it does not start playing when that is applied on test with a 9V PP3 via the UNO jack socket. Voltages seem OK: 5.0 on the UNO and 4.3 (after a diode) on the module. I also have precautionary 1k resistors on both the Rx and Tx pins of the module.

How can I fix this please? Is there some code I can add that will reset the program, simulating the reset button?


// Based on the Advanced example from DFRobot
// https://wiki.dfrobot.com/DFPlayer_Mini_SKU_DFR0299

#include "Arduino.h"
#include "SoftwareSerial.h"
#include "DFRobotDFPlayerMini.h"
#include <avr/wdt.h>

SoftwareSerial mySoftwareSerial(10, 11); // RX, TX (11, 10??)

// Create the DFPlayer Mini object.
DFRobotDFPlayerMini myDFPlayer;

void setup()
{

  // Initiate the DFPlayer.
  mySoftwareSerial.begin(9600);
  Serial.begin(115200);
  Serial.println("LoopAllFiles");


  // Check whether the DFPlayer is running accurately or not.
  if (!myDFPlayer.begin(mySoftwareSerial))    // Use SoftwareSerial to communicate with the DFPlayer.
  {
    Serial.println(F("Unable to begin:"));
    Serial.println(F("1.Please recheck the connection!"));
    Serial.println(F("2.Please insert the SD card!"));
    while (true);
  }

  //  myDFPlayer.setTimeOut(500); //Set serial communication time out 500ms

  //----Set volume----
  myDFPlayer.volume(10);  //Set volume (0~30).

  //----Set device; we use SD as default----
  //  myDFPlayer.outputDevice(DFPLAYER_DEVICE_SD);
  myDFPlayer.start();
  myDFPlayer.enableLoopAll(); //loop all mp3 files.
  while (1);
}

/////////////////////////////////////////////////////////////

void loop()
{
}

Your 9 volt battery can supply 9 volts, but VERY little current. Use a 5 volt cell phone charger at 5 volts to the ARduino 5 volt pin, Plus ground, of course.
Paul

There should be a warning on those smoke alarm batteries, "Do not use to power Arduino projects".

1 Like

@Terrypin Why is this in the programming section when it is a pure hardware problem?
So I have moved it.

I’m not so sure as you are that it couldn’t be a coding issue. But if it is hardware, do you have any suggestions?

And I did also include a specific coding question.

I did also try 4 x AA NiMh with same problem.

This was an initial test and later I tried four AA batteries wihich made no improvement.

And after a reset the PP3 immediately started the player. So that does not seem consistent with current limitation. That’s why I posted in the programming section, plus my query about a coding way of resetting as a possible work around.

If you use the power jack, the on-board voltage regulator will be used. It can't provide much current, so it's possible that it can't supply enough to run your player.

OK, understood. But as per my reply a few minutes ago I can’t square ‘it’s a power supply issue’ with ‘works OK after a reset’. But I’ll get into the shed workshop tomorrow and use two separate supplies for UNO and player module.

1 Like

If it works with battery power on reset, it sounds like it takes a little while to get started. Maybe try a few seconds delay before you ask the player to do anything.

1 Like

Have you tried using a lithium pack with a USB output to plug into your board instead. Quite often a small power bank will be enough to run simple projects that don't require a lot of power and you just recharge weekly (or whenever required).

1 Like

OK so you write some code that can differentiate where the power comes from. Without some monitoring of the voltage at various points in the circuit you can't do it.

No.
Vectoring through zero is the closest you can get to it but it will not do everything the reset button does.

If your processor is not running then having code to simulate a reset press is not a solution because your problem is that your processor is not running, so it can't run the code to simulate a reset in the first place.
But lets suppose that you could do this in software. How is the software going to distinguish that this is the second time the code has run? Without that the system would be stuck in an endless loop of resetting.

It is likely to be an issue related to the current capability or the impedance of the supply. Both these two are somewhat linked.

Too high a supply impedance will cause a slow rise time of the voltage and this could interfere with the auto reset function of the board. Batteries have a much higher impedance than the other sources of power. The lower the current capability of the battery the higher is the impedance.

When power is applied to a circuit that contains a capacitor ( and they all do ) there is an initial surge of current required from the power supply to charge up the capacitors.

It might very well be that your batteries can supply enough current to run the system once those capacitors are charged up, but not enough to cope with this initial charge current. I think this is what the "runs on batteries but only when I press the reset button" is all about.

The way to tell for sure is to look at the rise time on an oscilloscope. Removing capacitors from your circuit is not an option, they are needed for supply decoupling and ironically they help to actually reduce the impedance of a battery, once they are charged up.

Note impedance is not resistance although it is measured in ohms, try and think of it as a sort of resistance that changes with frequency.

1 Like

OK, thanks. Freezing in my shed workshop at present but when I get back to it I'll use the 'scope if my two bench supplies don't prove you right - as I hope they do! Might also try a couple of caps on the breadboard first too.

1 Like

Thanks. No, but sounds a good idea.

The actual project, assuming I overcome this and a few other problems, is a sort of music-come-trinket box as a possible Christmas gift for my wife. It must be battery operated and play within at most a couple of seconds of opening its lid. I had either 4 x AA NiMh in mind (or 4 C-types if space allowed), so your suggestion is timely.

BTW, I'll soon be tackling one of those 'other problems', noise from the player. Should I raise it here or start fresh post?

If it's related to the same project, best to stick to one thread so people get all the context.

After my reply an hour ago, impatient to continue the diagnostics, I found an old 1A iPhone USB charger cable, removed its regular plug and all but its 5V and ground wires, giving me an additional regulated and substantial 5V suppy. I applied the charger 5V via a diode to supply 4.3V to the player module, close to its midpoint of the datasheet's recommended 3.3 - 5.0. And 5.0V via the PC USB cable to the UNO. But that still failed to play on power up. No matter which of the two supplies I switched on first.

Then I confined the supply to only the charger, with same result.

But there's something else going on, because the manual reset no longer triggered play after those tests. Even after returning to the single PC USB supply. And closing the sketch and IDE then re-loading and using Upload no longer starts play.

Never on the same project! :face_with_raised_eyebrow:

I think everyone else is on a wild goose chase after you said
"9V PP3". The PP3 battery doesn't have a lot of capacity and can only power an Arduino project for a couple of hours. But that's OK for testing purposes. The DFRobot player will run as low as 3V3, so 4.3 is OK.

Draw a schematic showing how everything is connected.

Did you read my subsequent posts, such as this one?

“I did also try 4 x AA NiMh with same problem..”

Hi,
Can you please post a copy of your circuit, in CAD or a picture of a hand drawn circuit in jpg, png?

Can you please post a picture(s) of your project so we cab see your component layout?

Thanks.. Tom... :smiley: :+1: :coffee: :australia: