VS1053 over voltage risk

[Davidelvig]

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

[pasi]

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.

[Davidelvig]

Thank you!

[Davidelvig]

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]

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]

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!

[pasi]

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.