Connection Issues

Does the VS1053 have a pin labeled just as "CS"? When I look on Adafruit, I see a different looking board than what you have, but it does show a "CS" pin. This is the "select" pin that the master (MKR1000) uses to tell the slave to listen. Each slave must have its own "Chip Select" pin that cannot be shared. (Also call "slave select" or something similar.)

The next thing - How are you 'disconnecting' one or the other when you test? Just removing power or removing all wiring? And is all other wiring the same when the they work individually versus all wired in at ones?

In theory you should be able to have both all wired in, and run a test sketch one time for each board, just modifying the header info for the correct pinout. I would think that just removing power from the slave should effectively disable it so you can test the other board.

Does the VS1053 have a pin labeled just as "CS"? When I look on Adafruit, I see a different looking board than what you have, but it does show a "CS" pin. This is the "select" pin that the master (MKR1000) uses to tell the slave to listen. Each slave must have its own "Chip Select" pin that cannot be shared. (Also call "slave select" or something similar.)

The next thing - How are you 'disconnecting' one or the other when you test? Just removing power or removing all wiring? And is all other wiring the same when the they work individually versus all wired in at ones?

In theory you should be able to have both all wired in, and run a test sketch one time for each board, just modifying the header info for the correct pinout. I would think that just removing power from the slave should effectively disable it so you can test the other board.

It's not very clear but looks like the pins labelled MCS and DCS here: https://learn.adafruit.com/assets/16643

go to XCS and XDCS pins in that order, on the VS1053 chip according to the circuit diag here: https://cdn-learn.adafruit.com/assets/assets/000/016/642/original/adafruit_products_schem.png?1400269761

It seems the XCS pin is the chip select for the SPI interface? (chip datasheet: https://www.sparkfun.com/datasheets/Components/SMD/vs1053.pdf  )

Rob, how are you confirming that the MP3 shield is not detected? If you've not got a 'scope, you can use an LED and a resistor (e.g. 220 ohms) on the CS pin (i.e. MCS I think) to see if it stays permanently lit, or if it briefly flickers to off.

Also, could it be a supply issue? The display and MP3 shield combined may use more power than expected. Are you running this from USB?

Hi James,

Yes, the audio Shield does have that CS pin.

Here is information about the pins:

The underlined below is the Chip Select for the audio player.

The issue could be the VS1053 data select pin. That is pin 6 and the RA8875 uses pin 6 for the CS of the display.

The Music Maker shield has a bunch of pins required for use. We pre-wire all of them for you but there's still some flexibility in case you want to rewire.

There are three 'totally fixed' pins, the hardware SPI pins:

• SPI SCK - connected to Digital #13 (but can be connected to the ISP header with a jumper) - used by both the SD card and VS1053
• SPI MISO - connected to Digital #12 (but can be connected to the ISP header with a jumper) - used by both the SD card and VS1053
• SPI MOSI - connected to Digital #11 (but can be connected to the ISP header with a jumper) - used by both the SD card and VS1053

There are a couple other pins that are required for talking to the VS1053 to play MP3s and such

• MCS - this is the VS1053 chip select pin, connected to Digital #7
• DCS - this is the VS1053 data select pin, connected to Digital #6
• CCS - this is the SD Card chip select pin, connected to Digital #4
• DREQ - this is the VS1053 data request interrupt pin - connected to digital #3

Ther are also a few other pins that are not connected to any Arduino pin but are broken out:

• RST - this is the VS1053 reset pin, we connected it to the Arduino reset pin so you don't need to use this unless you really want to.
• SPK Off - this disables the amplifier - if you have the amplifier version and want to 'mute' instantly
• TX - this is serial data transmit from the VS1053 - its not used for any of our demos
• RS - this is serial data into the VS1053 - its used for MIDI synth playing
• CD - this is the card detect pin, it is tied to ground when a card is inserted. Use a pullup on a digital pin to detect when a SD card is inserted. We dont use it.

I connected the RA8875 to the MKR and ran a sketch and that was fine.

I disconnected all the cables and connected the VS1053 to the MKR and ran a sketch and it worked fine.

When I reconnected the RA8875 and VS1053 to the MKR and ran a sketch that included both the RA8875 code and the VS1053 code, neither worked.

I will try connecting both and just running the separate codes to see if that works.

If it does, that means the wiring is fine but something within the code or pins are causing the conflict.

Pin 7 is the CS for the VS1053, Pin 4 is the CS for the SD card and Pin 6 will be the CS for the RA8875.

I do not see how this would be conflicting but it could be.

I did read online that the SPI on the MKR doesn't handle different devices well using the different CS pins and that a tri-state buffer is needed to properly handle this.

Have you come across this before?

I will wire up the two devices (RA8875 and the VS1053 which includes the SD card) and run separate codes to see if each device works with the MKR.

If it does then I will combine codes with just basic code to detect items and see if that works.

If they do not work even with switching pins, then I will have to try to run the UNO with the VS1053 and the RA8875 with the MKR and get them to communicate either with TX/RX or I2C connections.

Hello Shabaz,

Here are the scenarios that happened this morning.

I connect the VS1053 to the MKR - RA8875 is not connected - Audio works fine when I run the simple player sketch. I verify that it is working and detected via the Serial monitor.

I then connect the RA8875 to the MKR while the VS1053 is connected and it will not display, the back light will not even turn on and the VS1053 will not play an audio file when I run the sketch.

I run the video sketch I have for touch screen buttons and it will not work.

I have to disconnect all the cables from the VS1053 in order for the RA8875 to operate after I run the touch screen sketch.

It seems like powering the RA8875 and VS1053 together with the MKR does not work even with the USB connection connected to the MKR1000.

I can connect the VS1053 to the UNO and power it that way and get the RA8875 to run with the MKR1000 but I am not sure how to make the MKR communicate with the UNO so audio is played when buttons are touched on screen from the RA8875 via the MKR unit. Right now having the MKR as the master and the UNO as the slave is not communicating either from TX/RX or I2C.

Hi Rob,

You may need access to a 'scope, but if that is not available, you could try a hack, where you stick an LED across both CS pins with a resistor (say 220 ohms) in series. Since Both CS lines should never be low simultaneously, you should see the LED light up in one direction (you could put two back-to-back).

If the two LEDs are both permanently off, then that's a sign that something is wrong.. You could try to pick a completely different pin to act as the CS pin on the MKR board, to see what happens. The code would need to select that line, or you'd need to do the selection at the point when the device that it is connected to needs enabling.

I'm just speculating if it is a CS line issue, it is hard to know for sure.

It could also be a supply issue, for that you'll need to use a multimeter to check the supply rail is still at 5V. Can you check that if possible?

Personally I think it's a lot harder if you use an additional UNO and try to communicate between the two. I would not try that, but it's really your decision. I think it's worth troubleshooting your scenario further, but it requires some way examining the signals, or seeing if you can adapt the code if you suspect there could be some clashes in the drivers perhaps.

Right now, to me, it points to either a chip-select issue, or a power supply issue. But I'm really guessing : ( I don't know for sure.

HI Shabaz,

I read online that there is an issue with the SPI section for the MKR1000 where unless you use a tri-state buffer chip, it has a hard time telling one CS pin from another which could be the issue that I am experiencing.