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.

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?

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.

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.

Hi Rob,

When the microcontroller is acting as a Master, then it's up to the slave devices (i.e. the VS1053 and RA8875 boards) to perform the tri-state operation, not the MKR board.

The MKR board just needs to instruct (by pulling the relevant CS line high) the slave devices to go tri-state on their MISO line. This is why it would be good to closely examine what is happening on your CS lines for the two devices. If the CS lines for both devices are simultaneously low, then that's a very bad thing.

The thing is, you don't need any SPI driver interaction to correctly control CS lines. You can define any connection on the MKR board to act as an output pin, and then write code (i.e. DigitalWrite) to pull the CS lines high or low under your own command, provided you put it at the correct location. It could well be the case that threads are executing that are pulling both CS lines low, That is not a MKR board issue, but could be a software or software driver issue.

This is all speculation though, and a way through this is to check the CS lines using the methods mentioned (ideally oscilloscope, or using LEDs).

A tri-state buffer chip could be used, but to me it sounds superfluous, unless there is some device-level reason why either of the devices is not going tri-state.

I don't know what the code looks like, but if you're executing a write to the display, it could be worth inserting a delay after that as a test, so that if the display is written in a different thread (I've never used the MKR board, I'm just guessing) then that thread has some time to complete before sending data to the VS chip.

Hello,

All I do is connect the RA8875 and the VS1053 to the MKR board and power it on and neither of them work even before I run any sketches.

I will try the LED process to see what is going on with the CS lines.

Hi Rob,

I had some questions:

(a) How do you confirm neither work before any sketches are run?

Are you observing power on LEDs or something?

(b) If you've got a way to confirm without running any sketch, what happens if you just disconnect the MISO line from one of the devices? Do the devices reach the failed state still, or remain in the working state? (prior to running the sketch, which of course will fail for one of the devices at least, since the MISO line is disconnected).

(c) What happens if you only connect one device fully, and only connect the power connections of the other device? Does one device work prior to running the sketch?

(d) What happens if, in scenario (c), you run the sketch?

Hello Shabaz,

I connected LED's with 220 ohm resistors and here is what happened:

1. With the RA8875 connected only, the CS LED would blink when powered on then it was low. When I touched the screen where the buttons were, the LED would brighten up as expected.

2. I connected the VS1053 with the RA8875 connected and added LED's for the board CS as well as the CS for the SD card.

     - The LED for the VS1053 board CS (MCS) would remain low the entire time.

     - The LED for the SD Card (DCS) would remain high the entire time.

     - The LED for the RA8875 would stay unlit the entire time (this is expected since the RA sketch is not running).

It seems as if the CS for the SD card is causing the systems to not play well together. Its staying high the entire time no matter which pin I plug it in and run the sketch.

If I run the Video sketch while everything is connected, the LCD will display the buttons but the VS1053 wont play the last audio files in memory like it does when I connect it stand alone on the MKR1000.

Since the MCS LED is low, I am taking it that this is normal until something is needed to be executed.

Since the DCS LED is high, I am taking it that this is not a normal situation. Again, this happens no matter which Pin I used. I even tried using an analog pin and the serial monitor asked if the SD card was connected.

With the LEDs in place, I will disconnect the RA8875 from the MKR and run the audio sketch again to see what could be causing the issues.

I will try with just disconnecting the power from the RA8875 first to see what that does.

Thanks again for the suggestions!

I am trying all that you are suggesting to see.

Hope my info helps... 

Hi Rob,

I'm not sure where the LEDs are connected (to ground, or to +ve, or across CS pins) so the information doesn't help me, but I think you've got the right idea, to use LEDs to examine the state of the CS pins if you don't have access to a 'scope.

The LED info isn't as meaningful until the sketch is run, because the CS pins are under the control of the MKR board and not the slave devices.

Also, I didn't understand your earlier text:

Hello,

All I do is connect the RA8875 and the VS1053 to the MKR board and power it on and neither of them work even before I run any sketches.

and I asked some questions related to it, specifically:

(a) How do you confirm neither work before any sketches are run?

Are you observing power on LEDs or something?

Anyway, to get to the bottom of this, I believe you just need to to confirm you have sufficient power, then observe what the CS pins do, and this should provide enough information to troubleshoot.

At some stage you may need to insert delays in the code and slowly see when the CS lines are asserted and deasserted, and see if it matches with what you expect.