Spark.process blocking for exactly 20 seconds

Troubleshooting
1

Hi,
I have a Core hooked up to a VS1053 MP3 board. I have the SYSTEM_MODE set to MANUAL and the first thing I do in my loop() is call

if (Spark.connected()) {
    Serial.print("?");
    Spark.process();
    Serial.print("!");
  }

Normally, everything is hunky dory. Whenever I play an MP3 using the VS1053, bad things happen. My print statements show that after a few seconds, Spark.process() blocks for exactly 20 seconds. Then the loop runs normally for a couple of seconds, then Spark.process() blocks again for 20. That continues forever.

It’s clearly some interaction of the VS1053 and the spark loop, but I don’t understand what could cause it. My only hunch are that the interrupt the VS1053 triggers when it needs more data is a problem. When looking at what spark_protocol.event_loop actually does, though, I don’t see how a separate interrupt that triggers a static method call for the VS1053 buffers could cause problems.

Any thoughts?
Ryan

2

You can consider using SEMI_AUTOMATIC and use Spark.process() in loops that are long blocking, not allowing loop() to iterate.

3

Good thought. I tried SEMI_AUTOMATIC, and it does exactly the same thing. The core calls loop() regularly for a few seconds, then doesn’t call loop() at all for exactly 20 seconds. Then calls it for a few seconds, then doesn’t call it at all for exactly 20 seconds.

When I changed the VS1053 from using an interrupt to a timer, that works. It’s definitely something to do with the interrupt.

1 Like
4

I’ve found that if you call Spark.connect() will block for about 20 seconds when you can’t reach the spark cloud.
I’m guessing you are not connected to the cloud and can’t reach it for some reason (no network? bad creds?)

5

Good to know that it might be connectivity related. It’s definitely connected when the mp3 starts playing, and I make sure that spark.Process is called many times each second even during playback. Simply swapping out the interrupt for a timer fixes the problem, though the effect is basically the same: call the playback method multiple times each second.

6

I found this other thread with @McTristan and @peekay123 talking about the exact same problem: Adafruit VS1053 (mp3) library for music maker shield ported?

I’ve found that in my case, it’s also certain MP3 files, but it’s not associated with bitrate. I have some 32kbs files that work great, and others block the thread.

Did either of you guys ever figure out the real issue with this?

Thanks!
Ryan

7

A guess: spark.process() has a 20 second timeout if waiting on communication from the cloud. If your ISRs cause the core to miss a message from the cloud (CC3000 buffer fills up while you’re in the ISR) , it will sit in spark.process() waiting for the lost message.

I’m not familiar enough with the adafruit library, but generally you want to

  1. make ISRs as short as possible as to not block any important processing from going on (reading from the CC3000 )
  2. Disable interrupts while running critical code.

It sounds like you either need to run disconnected from the cloud while playing music, disable your interrupt while calling spark.process() or modify the ISR to run much shorter.