VS1053 over voltage risk

Writing software for systems that use VLSI Solution's devices as slave codecs to a host microcontroller.
Post Reply
Davidelvig
Senior User
Posts: 38
Joined: Mon 2015-08-24 5:25

VS1053 over voltage risk

Post by Davidelvig » Wed 2020-06-03 6:12

I’ve just populated my second board design with the VS1053.
The first worked well.

Another device on the new board shares the 1.8v power source.
It has been pulling 1.8v up to 2.65v

I’ve cut the trace to that other chip, and now the VS1053 has a 1.8v input.

The VS1053 is not working as expected yet (serial MIDI in, audio headphones out)

1) Is there any chance I’ve fried the VS1053?
2) it these a step-wise set of testing instructions to assess the chip functions?

Thanks

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

Re: VS1053 over voltage risk

Post by pasi » Wed 2020-06-03 10:54

Breakage is of course possible, but there's a good chance nothing broke.

Use the normal development cycle if you can.
- when xRESET is high, do you see a) xtal oscillating, b) RCAP, LEFT, RIGHT, GBUF go to about 1.2V, c) DREQ raise.
- test SCI register reads and writes. If you see 0xac45 in SCI_AUDATA, the chip is in RTMIDI mode.
Visit https://www.facebook.com/VLSISolution VLSI Solution on Facebook

Davidelvig
Senior User
Posts: 38
Joined: Mon 2015-08-24 5:25

Re: VS1053 over voltage risk

Post by Davidelvig » Wed 2020-06-03 17:01

Thank you!

Davidelvig
Senior User
Posts: 38
Joined: Mon 2015-08-24 5:25

Re: VS1053 over voltage risk

Post by Davidelvig » Mon 2020-06-08 0:09

OK, I did have a wiring problem with XRESET, which is now addressed.
After that fix (and resetting with XRESET LO for 100ms then left at HI), I get:
- RCAP, LEFT, RIGHT and GBUF all are at 1.2v

...but DREQ stays low

I have the following set up with resistors at startup.
- GPIO0 pulled LO to 0v; and
- GPIO1 pulled HI to 3v3

This function...

Code: Select all

int cmdValue = dbM.readSCIRegister(0x5);  // SCI_AUDATA = 0x5
calling...

Code: Select all

uint16_t dbMIDISynth::readSCIRegister(uint8_t _reg) {
    if (!_use_VS1053) return(0);
    uint16_t result;

    // waitForDREQ(10);
    spiOn(VS1053_CommandSlaveSelectPin);
    SPI.transfer(0x03); // Read operation
    SPI.transfer(_reg); // Which register
    result = SPI.transfer(0xff) << 8; // read high byte
    result |= SPI.transfer(0xff); // read low byte
    spiOff(VS1053_CommandSlaveSelectPin);
    // waitForDREQ(10);
    return result;
}
returns 0.
I've confirmed that the XCS pin drops to LO with spiOn()
I am seeing appropriate chatter on the RX pin (appropriate for the test MIDI messages I am sending.)

I occasionally (unpredictably) find DREQ at 3V3, though it's at 0v after start-up, and almost all of the time.

There has been no audio through the earphones.

Any more insights with the above data?

Davidelvig
Senior User
Posts: 38
Joined: Mon 2015-08-24 5:25

Re: VS1053 over voltage risk

Post by Davidelvig » Mon 2020-06-08 15:19

I've just found that the 12.288 crystal is not oscillating when the above symptoms exist. When the crystal oscillates, I get proper pin values.
I'll let you know what I find out.

Davidelvig
Senior User
Posts: 38
Joined: Mon 2015-08-24 5:25

Re: VS1053 over voltage risk

Post by Davidelvig » Mon 2020-06-08 18:54

All appears when when the crystal is oscillating, and the SPI query you suggested returns the correct result. I had a bad connection at the 1Mohm resistor.

Now the crystal starts oscillating on power up.
I'm still tracking down a failure to oscillate when I perform a reset on my main processor chip, but I have a reproducible test set (and steps to succeed and fail).

My EE colleagues are a bit puzzled as to why the 1Mohm resistor is critical. They have not seen that feature on other crystal designs.

Do you have any insights as design intent of the big resistor across the crystal pins?

Thanks for your help!

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

Re: VS1053 over voltage risk

Post by pasi » Tue 2020-06-09 10:33

If the internal capacitance of the crystal and/or the capacitance of the traces on the PCB are too high, too large capacitors to ground can prevent the oscillator from starting.

The 1MOhm resistor is biasing XTALI and XTALO to a point of highest gain and away from stable states where the crystal doesn't oscillate.
Visit https://www.facebook.com/VLSISolution VLSI Solution on Facebook

Post Reply