How can loop() affect setup() actions?

Projects Programming
1

After a recent edit of (for me) a fairly complex project I have an issue that seems somewhat illogical.

Libraries in use
----------------
#include <OneWire.h>
#include <RTClib.h>
#include <DallasTemperature.h>
#include <LiquidCrystal.h>
#include "SoftwareSerial.h"
#include "DFRobotDFPlayerMini.h"

I've always assumed that setup() cannot be affected by whatever happens in loop(). But that seems to be what's happening here.

Directly before the end of setup() I test a few MP3 files to check my DFR Player module is initialised OK.

void  setup()
// Other code 
// Play a few MP3s before proceeding
for (int i = 1; i < 5; i++)
    //    for (int i = 140; i <= 144; i++)
  {
    Serial.print(F("About to play track "));
    Serial.println(i);
    myDFPlayer.play(i);
    delay(500);
  }
  Serial.print(F("Setup ended, millis = "));
  Serial.println(millis());

If add the line

while (1 == 1); // Stops program from proceeding

then I get this familiar, correct result:

With sketch 'stopped' at end of setup()
---------------------------------------
About to play track 1
About to play track 2
About to play track 3
About to play track 4
Setup ended, millis = 7674

But with that while() commented out and loop() therefore running this is the printed output.

With loop() running
-------------------
About to play track 1
About to play track 2

I'm baffled why only two of the four are played, and setup() is not finished.

It clearly involves the player code. I'm about to start the debugging by comparing the backup made directly before my latest edit of loop(). I'll report any new info, but meanwhile can someone please explain the general question of how code in loop() can ever affect setup(), as it appears to have done in this case?

2

where is this added?

please post the entire program?

3

At the end of setup().

4

???

5

How would 4500 lines of code help answer the general question I asked in my last sentence?

6

Just looking at the above code... setup is not even bounded. i.e.
Setup{
my code here
}

without the code, its hard to help find a solution.

7

It might allow someone to have any idea what's going on.

If you don't post the code, make a minimal example sketch that illustrates the problem. A sketch that compiles, runs and does the same thing, so we can compile it, run it and see the same thing.

Imma bet that as you work to do that, you will see something that we haven't, because we can't, so far, that solves it.

a7

8

It sounds like something in loop() is causing a reboot thus causing setup() to run again

3 Likes
9

i believe a 100 line program can demonstrate the problem

so i'll guess that with the processor trapped in the while loop it is unable to service the Serial output transmitter, moving byte from a buffer to the UART

10

That would be really easy to check if @Terrypin thought about it for a second. Just add a one-time print statement near the beginning of setup(), before the 'for' loop.

11

Yes.

@Terrypin put your infinite loop show-stopper as the first line of code in the loop() function.

void loop() {
  while (1);

// 44964 more lines of code what will never kill you de
12

it can't and you are interpreting results wrong.
Make a minimal running (=compileable) example showing the problem.

13

Hey, give me a chance! I read @UKHeliBob's thoughtful suggestion about two minutes before seeing your critical post, and was about to take the obvious step to check.

A tad too quick to rattle off an insult I think.

These extra lines in setup()

byte setupCount = 1;
Serial.print("setupCount = ");
Serial.println(setupCount);
setupCount++;

gave this result

setupCount = 1

About to play track 1
About to play track 2

So no reboot. I'll now take a look at the other suggestion from @gcjr

14

Thanks that sounds very plausible. So it can happen, contrary to my assumption. Squares with what I've seen of this DFR player's sensitivity to timing.

It should take far less than 100 lines of code to examine. As I said, I'm stepping through Before and After versions. Only a score of lines differ, in one section, so hoping it shouldn't be long to isolate the cause.

15

i think my guess is wrong based on following
so i'd like to see more of the code or a partial complete version that demonstrates the problem

output

now is the time for all goo men to come to the aid of their party
now is the time for all goo men to come to the aid of their party
now is the time for all goo men to come to the aid of their party
now is the time for all goo men to come to the aid of their party

char s [] = "now is the time for all goo men to come to the aid of their party";

void
loop (void)
{
}

void
setup (void)
{
    Serial.begin (9600);
    for (int n = 0; n < 4; n++)
        Serial.println (s);
    while (1)
        ;
}
16

It could be possible if something in the larger code disable interrupts.

17

Your code crashes :wink: The symptoms can be different but in this case it seems to cause a reset of the board.

You will have to dig through all your array variables and check if you don't write (and read) outside their boundaries. You will also have to check if you properly use String (capital S) variables and check the use of libraries that dynamically allocate memory (e.g. Neopixel).

1 Like
18

@sterretje
Thanks, much appreciated. I'm on it and will report back.

19

Who/what were you answering?

Not sure if you were being serious, but if so why would that make any difference? I did it anyway and it doesn't. Still plays all four in setup.

20

It was when the infinite loop was present that all four lines were printed. Without the infinite loop, printing stops a few lines short.

a7