VS1063 will not accept commands

[jimlake]

I have used the VS1063 successfully in many projects, but I'm having a weird problem with my latest and hope you might be able to suggest a solution. I am controlling the 1063 with an Atmel 1284P microcontroller. The uC reads data from an SD card via harware SPI, stores it in a ring buffer, and feeds it 32 bytes at a time to the VS1063 via another SPI. I've used the same system before and it works fine.

The problem in this case is the VS1063 appears to be working, all voltages and grounds are correct. The hardware design is identical to the schematic in the data sheet. However, the device will not accept commands. If I send data to it, I can see the data required line go up and down, as I would expect. If I read the contents of the status register, I get back 0x4800, again as I expect. But if I try to turn on sine tests, nothing happens, no sine output. If I turn on the memory test, the contents of the HIDAT0 register is 0x00, not as I would expect. when I send it audio data (mp3), I get no audio output. I have a good 12.288MHz clock on the XTL and XTO pins.

I have swapped the VS1063 IC's with one I know works, same results. I have used the software on another board with the same devices (different design) and it works fine there. I have followed the continuity of every signal from origin to destination. I have monitored the data and commands on the pins of the VS1063. GBUF is 1.2v. The physical layout of the chip and its peripheral components follows the guidelines in the data sheets.I am loading the user plugin and changing the clock and the status of the DR signal indicates that is successful.

Can you suggest something else I can try or test I can perform to uncover what the problem is?

[Panu]

Hi, and thanks for your thorough problem description!

You've done a good analysis of the clock, could you similarly describe the states of all three supply voltages, as well as the RESET and TEST signals?

-Panu

[jimlake]

Thank you, Panu, for getting back to me on this. Voltages follow:
CDVD pin
5 1.72
7 1.72
24 1.72
31 1.72
AVDD pin
38 3.31
43 3.31
45 3.31
IODVD pin
6 3.31
14 3.31
19 3.32
XTEST pin 32 3.32
RESET pin 3 3.31

[pasi]

Check that there are no short-circuits in the analog outputs.

Your CVDD is a little low at 1.72V (1.8V nominal), but should work unless you "overclock". What's the SCI_CLOCKF value you use?

The "old" sine test requires that both SCI and SDI communication work. Have you tried the new sine test version?

[jimlake]

Here is some additional information. I am turning on the test mode by sending SCI_MODE the value 0x4820 and the CLOCK_F: 0x6000 for a clock multiplier of 3, (3 x 12.288 = 36.86 MHz) which should be sufficient for mp3.
However, when I immediately read SCI_MODE, I get 0x4800, rather than 0x4820. There is a note in the data sheet that says that hardware resets this to 0x4800. So, should I read 0x4820 or 0x4800 in the MODE register? I can set the other registers, but I can't set this one.

For SCI_STATUS I get 0x60, which apparently means the analog engine is running. If I read SCI_CLOCK_F, I get 0x6000, indicating I did set the clock multiplier.

I will kick the CVDD voltage up to 1.8, but I don't think that will help because I have other VS1063 boards running just fine at 1.72v

I checked the continuity of all of the AVDD pins. They all look OK.

I will also try the new sine tests.

[jimlake]

I tried to initiate the new sine test by sending (sine sweep) 0x4022 to SCI_AIADDR. I get no output, but I notice that SCI_STATUS changes from 0x60 to 0x04, which the datasheet claims indicates an analog power down. Is this to be expected?

[pasi]

when I immediately read SCI_MODE, I get 0x4800, rather than 0x4820. There is a note in the data sheet that says that hardware resets this to 0x4800. So, should I read 0x4820 or 0x4800 in the MODE register?

You should get back 0x4820. So, either you are performing the write before the vs1063 has started, or your SCI writes do not fully work.

When you deassert reset, the crystal oscillator leaves powerdown, and when the amplitude is high enough, the chip will leave reset state. If the capacitors from the crystal to ground are too large compared to the internal capacitance of the crystal, it may take a long while for the oscillator to start.

Are you waiting for DREQ to rise before performing SCI writes? Is the SPI speed low enough at this stage? (XTALI/7)

If you first read 0x60 from SCI_STATUS, and then read 0x04, you note that the SS_VER field has been corrupted. Your SCI read may not be performing correctly, SCI write has corrupted the register, or... Well, the write to SCI_AIADDR didn't work as expected.

It is not necessary to write SCI_MODE for the new sine tests. When I write 0x4022 to AIADDR (and 0xbb80 to AUDATA to make the sweep faster), I'm still reading 0x0060 from SCI_STATUS and 0x4800 from SCI_MODE.

[jimlake]

I have not worked on this project for a while, and I am just getting back to it. The delay has given me a chance to see some additional things going on with this issue.

I have discovered that the circuit works fine, if it is running free. The problem happens when I try to run it under the control of the Atmel Studio v7 debugger. For some reason that I do not understand, when I am running a debugging session on the AT Mega 1284P, the VS 1063 does not toggle the DATA REQUIRED line at all. I have put a scope on DR and observed that when its running free, the DR line toggles every few mS. But, when I start a debugging session and tell it to run the code, the code runs fine, but the VS1063 stops calling for data. Stop the debugging session and reboot, the circuit works perfectly.

So, my question to you guys is, obviously, have you any idea what might cause that sort of behavior?

[pasi]

Which pins are used by/for the debugger? Which pins are connected to the vs1063a?

[jimlake]

No, I don't think its that because the JTAG pins used by the debugger are dedicated to just that task. The VS1063 uses a SPI on different pins and DR is also on its own pin. I have attached the schematic, if you have a moment to look at it. I was able to debug it without the AS7 debugger and its working the way I want, but it would be illuminating to know what causes this.