I’m trying to use an Adafruit Music Maker to play MP3 files which I’ve saved onto a 32GB SD card. I’m using the feather_player.ino example file to get acquainted with the board, but had to change the #define statements in order for the Music Maker board to be seen. BTW, I’m using an Argon for this project and I changed the SD card library include from #include <SD.h> to #include <SdFat.h>
Once I changed the final default define statements to the following, the Music Maker board is now seen, but I’m still having trouble getting it to read the SD card.
// Feather M4, M0, 328, nRF52840 or 32u4
#else
#define VS1053_CS 3 // 6 VS1053 chip select pin (output)
#define VS1053_DCS 5 // 10 VS1053 Data/command select pin (output)
#define CARDCS 2 // 5 Card chip select pin
// DREQ should be an Int pin *if possible* (not possible on 32u4)
#define VS1053_DREQ 4 // 9 VS1053 Data request, ideally an Interrupt pin
#endif
The numbers after the // indicate the original values as the library was ported, but they did not seem to work. Any suggestions would be greatly appreciated.
Just to clarify, I’m getting the SD failed, or not present error message from the example program.
Also, I’m using a doubler to connect the Argon to the Music Maker side by side.
@ScruffR, I believe the library you ported is the one I’m using in the IDE. I simply used the feather_player example, but will try the example you referenced to see if that makes any difference. I also didn’t understand the required file structure, so I added a 01 folder to the root level and placed my mp3 files in there, instead of simply leaving them at the root level. I’ll give that a whirl. Thanks!
I only added a sample that works with Particle devices - I didn’t go through the elaborate task of porting all the samples.
But taking the Particle samples and applying its essence and combine that with any of the features illustrated in the stock samples should provide the keys to the whole feature set.
My app is seeing the SD card and I’m able to see the list of MP3 files. Still not getting sound other than the sine wave, but I’m powering via my USB port from my MacBook Pro and it may not have enough power.
I see, I have now tested with a Boron on 1.5.0 and see the solid cyan after initiating an MP3 playback. Some kind of deadlock I presume
I’d have to see what changed on the device OS side to cause this “new” behaviour.
This didn’t use to happen when I ported the library. Others have also used the lib in the past and didn’t see this issue.
I connected my Argon to a 5Vdc 3A supply and I still get the brief sine tone upon start as expected.
When I call the playTrack function and pass it a “1”, I believe it starts to play the 001.mp3 file, but stops after about 1 second and the LED stays solid cyan. As I mentioned above, I created a folder named 01 and put three files in it: 001.mp3, 002.mp3 and 003.mp3. If I try to call playTrack passing either 2 or 3, nothing happens.
The 001.mp3 file is a 30 second clip. Are there any special requirements for the mp3 files?
Should I try to downgrade my Argon to something like 1.4.n?
I finally was successful in downgrading to 1.4.1 via the IDE with Particle: Compile application and DeviceOS (local) and then Particle: Flash application and DeviceOS (local) and it works!
I’m hoping the library gets updated at some point in time so I can update my Argon and app to the current release. Thanks for porting this in the first place and I appreciate your guidance today.
@avtolstoy, any update on when you might be able to help resolve the issue that would allow this library to run under 1.5.0?
[update] To provide some context…a couple years ago I developed an app that would sense motion in the backyard after dark and turn on the irrigation sprinklers to “encourage” deer to leave the yard before destroying my wife’s flowers. It has worked fairly well, but I’m trying to add a feature that will also play coyote sounds in the back yard to further “inspire” them to leave. I’m trying to use the Adafruit Music Maker to accomplish this. I can get my app to run under 1.4.1, but with some issues and I’d love to be able to update my Argon to 1.5.0 to clean up any OS mess I’ve created trying to upgrade/downgrade/etc.
Yes, this is not a crucial app…except from my wife’s perspective and therefore mine, too.
The issue was encountered probably by noInterrupts() being called before sciWrite() in the music driver. The sciWrite() will invoke wiring hardware SPI.transfer(void* tx_buffer, void* rx_buffer, size_t length, wiring_spi_dma_transfercomplete_callback_t user_callback), which requires a user callback, otherwise, SPI.transfer() will block until transmission completed. noInterrupt() masks the SPI interrupt, so it blocks in SPI.transfer() .
Could you try removing the noInterrupts() and see if it blocks?
Thanks @ielec for the suggestion, but unfortunately it didn’t help.
I removed all occurances of noInterrupts() and interrupts() and replaced them with a simple guard flag that should prevent calling the user defined callback.
However, this still blocks after a split second of playing back the selected MP3 file
I thought I’d try upgrading the Argon to the 1.5.1-rc1 release to see if it would in any way help the situation. Unfortunately, I can’t get the app to compile due to a SDFAT library compile error. Evidently something has changed with rc1.
I’m getting the following compile error:
/Users/tom/Documents/Particle/Projects-Home/CoyoteSound/lib/SdFat/src/SdCard/../SpiDriver/SdSpiDriver.h:38:20: error: conditional expression between distinct pointer types 'SPIClass*' and 'particle::SpiProxy<(HAL_SPI_Interface)0u>*' lacks a cast
#define SDCARD_SPI SPI
Any thoughts would be appreciated. If I’m simply wasting my time, I’d like to know that, too!
Quick question…I tried downgrading to 1.2.1 as per your earlier suggestion as a work around (well…you recommended a downgrade as a possible solution). I flashed Tinker for 1.2.1 and then I put my Argon into DFU mode and flashed 1.2.1. I immediately get S.O.S. with 10(?) blinks and I’m not able to get past this without simply doing an upgrade as a way out. I thought a downgrade from 1.5.0 to 1.2.1 was a pretty simple process, but I recall trying to downgrade to 1.4.1 was a headache, too. I’m obviously doing something wrong.
[update] Well…after flashing 1.2.1 it actually appears to remain in DFU mode forever. It’s only until I restart the device that it goes into SOS mode.
Here’s the output from particle flash --usb argon-system-part1@1.2.1.bin -v
dfu-util 0.9
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 2b04:d00c
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 4096
DfuSe interface name: "Internal Flash "
Downloading to address = 0x00030000, size = 630672
Download [=========================] 100% 630672 bytes
Download done.
File downloaded successfully
Flash success!
Flashing a application that is targeted at a previous device OS does not downgrade the already installed device OS since old applications can run under new OS.
You need to explicitly flash the device OS binaries of the version you want.
Oops, answered before reading the entire post - you already knew that
Just updated to 1.5.1 and Eureka!!! Everything works! Thanks @avtolstoy and whomever else for making this happen!!! This also resolved the SdFat issue. Woohoo!!!
The firmware is not yet available on the IDE, but assume it will be soon. In the meantime, I merely moved my application over to “build” and was able to get it done.
