VS1053B + Raspberry Pi

Writing software for systems that use VLSI Solution's devices as slave codecs to a host microcontroller.
Post Reply
User avatar
ernastovich
User
Posts: 3
Joined: Fri 2020-09-25 7:41

VS1053B + Raspberry Pi

Post by ernastovich » Fri 2020-09-25 8:11

Hello!

I hope people still utilize this website, as I am seeing mostly very old posts.

I'm having some troubles with my VS1053b, and after scouring the internet and the datasheet and the application notes, I have resorted to that most heinous crime for any man... admitting defeat and asking others for help.

I see most people are using the VS10xx chips with PIC μcontrollers + some memory. I am attempting to use it with the Raspberry Pi (2B) GPIOs instead.

I should qualify before everything that my vs1053b was purchased as a pre-assembled breakout board, which should (allegedly) be usable with headphones. Link to the board -> https://www.amazon.com/HiLetgo-Recordin ... s9dHJ1ZQ==

I have checked the circuitry of this board, voltages and continuity, and it appears to be correctly hooked up based on the vs1053 datasheet hookup scheme/power requirements.

Furthermore, I'm having a peculiar situation where the SCI functions are completely operable and functional.
I can read from and write to the SCI registers. Everything appears to be coming up correctly. However for some unknown reason, I cannot get any mp3 file to actually get decoded and play (no SDI functionality).

Some background information, I am using "new mode" aka separate Chip Selects for SCI and SDI. I have analyzed the signals on my oscilloscope, and they are functioning properly (i.e. xCS goes low for SCI, and xDCS goes low for SDI), and the SCI_MODE register reads 0x4890 by default (I change this to 0x48B0 for SDI TEST.

I have also used the oscilloscope to read the SPI bus while I transmit data to SDI,
SDS00002.png
SDS00002.png (24.03 KiB) Viewed 385 times
The signal we're seeing here is the partial SDI_TEST MOSI line superimposed on the CLK. And yes, I did prepare the VS1053B for SDI test in the SCI_MODE register prior to sending the SDI test bits.

Whether I send an MP3 file, or the SDI TEST, the vs1053 only makes a slight blip (almost like the transient we hear when headphones are first plugged in), and nothing else. Whats more disturbing is that the DREQ signal never goes low during SDI transmissions.... To me it sounds almost impossible that a 30 second 700kB file can be transmitted to the vs1053b SDI input buffer without ever overflowing.

I have set up level transition detection on the raspberry pi GPIO for DREQ, and if I write an SCI command (read, write, doesn't matter) The DREQ line DOES indeed go LOW momentarily while the chip processes the SCI command.

I did think about the mp3 file being corrupted, and I have tried to replace the file with a totally different file, the behavior remains unchanged.

I am at a loss, i'm not inclined to condemn the chip as of yet considering the functional SCI registers, but without help, that is my final option.

Thanks for reading my essay, I hope you may be able to point out some glaring error!

P.S. The chip operates on 12.288 MHz, I am not using any clock multiplication, I have varied the SPI CLK speed from 120kHz all the way to 7.8MHz (double increments as provided by the bcm2835 SPI library).

User avatar
Panu
VLSI Staff
Posts: 2766
Joined: Tue 2010-06-22 13:43

Re: VS1053B + Raspberry Pi

Post by Panu » Fri 2020-09-25 9:09

Hi!

Yes, we're active :D

I'm not familiar with that board, but my first hunch would be that the chip might be in factory test mode. I found a picture of the board from your link. Can you check from your board, is the XTEST pin floating? It should be pulled high.
xtest_pin.png
xtest_pin.png (235.54 KiB) Viewed 384 times
If the chip is in factory test mode, the SCI registers work, because they are a hardware block. But the chip is not running normal software, it's running factory test software. So complex functions such as MP3 decoding wouldn't work.

-Panu
Info: Line In and Line Out, VS1000 User interface, Overlay howto, Latest VSIDE, MCU Howto, Youtube
Panu-Kristian Poiksalo, VLSI Solution Oy

User avatar
ernastovich
User
Posts: 3
Joined: Fri 2020-09-25 7:41

Re: VS1053B + Raspberry Pi

Post by ernastovich » Sat 2020-09-26 7:45

Awesome!!

Okay, I checked the XTEST pin, and it is indeed being pulled high to ~3.3V, however, while I was in there I decided to verify some of the other pins as well (using the datasheet sample circuit as a guide).

What do you make of this revelation: The UART RX pin is tied directly to the 3.3V bus (it appears they have omitted the 100kΩ resistor), furthermore - and perhaps more troubling, the TX pin is ALSO being pulled high to 3.3V which is contrary to the datasheet. Does this sound like a potential culprit?

Thanks again!!

User avatar
ernastovich
User
Posts: 3
Joined: Fri 2020-09-25 7:41

Re: VS1053B + Raspberry Pi

Post by ernastovich » Sun 2020-09-27 9:07

It worked!!

The problem is pin 34 GPIO 1.

The board has this pin FLOATING, instead of grounded, I suppose for this reason the chip was booting into MIDI mode, rather than MP3 decoder mode.

I simply tried shorting the pin 34 with the pulled-down pin 33 with my multimeter probe, and the chip started to play the mp3 file my code was sending! (albeit with HORRIBLE quality which I will now begin troubleshooting).

So there we go! hopefully this solution is helpful to others! Make sure the GPIO 1 pin is grounded upon booting up!
A5C5E514-94DE-4F8A-8D65-1F2755679C85.jpeg
A5C5E514-94DE-4F8A-8D65-1F2755679C85.jpeg (2.19 MiB) Viewed 362 times

User avatar
pasi
VLSI Staff
Posts: 1730
Joined: Thu 2010-07-15 16:04

Re: VS1053B + Raspberry Pi

Post by pasi » Mon 2020-10-19 12:10

vsX053b booting into Real-Time MIDI mode is one of the common hurdles people encounter.

You can detect this by reading SCI_AUDATA during the software startup. You will see 0xac45 if the 53b is in MIDI mode, the normal value 0x1f40.
Visit https://www.facebook.com/VLSISolution VLSI Solution on Facebook

Post Reply