Unreliable Reset of VS1053

Writing software for systems that use VLSI Solution's devices as slave codecs to a host microcontroller.
dandynstuff
User
Posts: 14
Joined: Mon 2017-03-13 18:51

Re: Unreliable Reset of VS1053

Post by dandynstuff » Sun 2017-03-19 16:27

added pulling the data-cs-line up before using sci, just in case, but no change... When I read hat0 and hat1 after reset and they aren't both zero, I can simply do another reset untill they are 0, but it's quite annoying and puzzling. Any other ideas, what this could be, or what I should try? Thanks

User avatar
Henrik
VLSI Staff
Posts: 1034
Joined: Tue 2010-06-22 14:10

Re: Unreliable Reset of VS1053

Post by Henrik » Mon 2017-03-20 14:18

dandynstuff wrote:Thanks.
When I have 24001 in AUDATA, I read
HDAT0 = 0
and HDAT1= 1023
HDAT1 = 1023 can really only occur when VS1053 is in encoding mode. In this situation, could you read and print out register contents of SCI_MODE, SCI_STATUS, SCI_CLOCKF and SCI_AICTRL0 - SCI_AICTRL3?

Kind regards,
- Henrik
Good signatures never die. They just fade away.

dandynstuff
User
Posts: 14
Joined: Mon 2017-03-13 18:51

Re: Unreliable Reset of VS1053

Post by dandynstuff » Sat 2017-04-01 19:58

Yes, thanks, I get these results:
Reset ok:
2048
64
24576
0
0
0
0

Examples of Reset gone wrong:
6144
64
24576
0
0
65535
0

6144
64
24576
0
7
65535
32815

6144
64
24576
0
263
65535
33071

Also, it seems when I reset the microcontroller, after that everything is fine, but when I use the reset-routine I programmed, it sometimes works, sometimes does not. In a way it seems the microcontroller and the 1053-chip get out of sync somehow...

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

Re: Unreliable Reset of VS1053

Post by pasi » Mon 2017-04-03 11:50

If the first number is the content of SCI_MODE, then it does seem like our guess was correct: you are somehow starting the encoding mode in your software reset routine (6144 = 0x1800 is ENCODE + NEWMODE).

Check your SPI speed and SPI mode - it looks like you may be changing the SPI data on the same rising edge as the vs10xx uses to read the data, which could cause wrong data to be written. I.e. when you try to write 0x0804, the value is received as 0x1804, causing the software reset to start the encoding mode.

SPI mode 0 is usually the correct one.
Visit https://www.facebook.com/VLSISolution VLSI Solution on Facebook

User avatar
Henrik
VLSI Staff
Posts: 1034
Joined: Tue 2010-06-22 14:10

Re: Unreliable Reset of VS1053

Post by Henrik » Tue 2017-04-11 9:13

Hello!

Just out of interest, were you able to solve your issue?

Kind regards,
- Henrik
Good signatures never die. They just fade away.

Brek
Senior User
Posts: 47
Joined: Sun 2016-09-11 5:51

Re: Unreliable Reset of VS1053

Post by Brek » Thu 2017-04-20 8:28

Hi, That’s the same module I used before making my own board, only mine was populated with vs1003b.

It looks like you are waiting for the chip to be ready after the hardware reset which is good.
Here is how I set a clock value for example:

Code: Select all

while (VSDREQ == 0) {delay_ms(0);} // wait for chip to be ready
VSXCS = 0; // select vs1003 instruction
WriteSPIManual(0x02); // write
WriteSPIManual(0x03); // clock register
WriteSPIManual(0x00); // zero
WriteSPIManual(0x00); //
VSXCS = 1;
and here are proven software spi functions that I use right up until the correct clock value has been read back from the chip,
which happens first time every time in my experience.
Then, so long as the clock value that was set was high enough, some fast hardware spi can be used from then on.
It was enough delay for me to just call a delay function with a value of zero.. that was enough delay in itself for me.

Code: Select all



unsigned char WriteSPIManual(unsigned char data_out) {
// vs1003b chip receives slow spi until it's clock is set.
char i = data_out;
SPICLOCKLAT = 0;
SPIOUTLAT = 0; // 1
SPICLOCKLAT = 0;
if (i & 0x80)
SPIOUTLAT = 1;
else
SPIOUTLAT = 0;
delay_ms(0);
SPICLOCKLAT = 1;
delay_ms(0);
SPICLOCKLAT = 0;
if (i & 0x40)
SPIOUTLAT = 1;
else
SPIOUTLAT = 0;
delay_ms(0);
SPICLOCKLAT = 1;
delay_ms(0);
SPICLOCKLAT = 0;
if (i & 0x20)
SPIOUTLAT = 1;
else
SPIOUTLAT = 0;
delay_ms(0);
SPICLOCKLAT = 1;
delay_ms(0);
SPICLOCKLAT = 0;
if (i & 0x10)
SPIOUTLAT = 1;
else
SPIOUTLAT = 0;
delay_ms(0);
SPICLOCKLAT = 1;
delay_ms(0);
SPICLOCKLAT = 0;
if (i & 0x08)
SPIOUTLAT = 1;
else
SPIOUTLAT = 0;
delay_ms(0);
SPICLOCKLAT = 1;
delay_ms(0);
SPICLOCKLAT = 0;
if (i & 0x04)
SPIOUTLAT = 1;
else
SPIOUTLAT = 0;
delay_ms(0);
SPICLOCKLAT = 1;
delay_ms(0);
SPICLOCKLAT = 0;
if (i & 0x02)
SPIOUTLAT = 1;
else
SPIOUTLAT = 0;
delay_ms(0);
SPICLOCKLAT = 1;
delay_ms(0);
SPICLOCKLAT = 0;
if (i & 0x01)
SPIOUTLAT = 1;
else
SPIOUTLAT = 0;
delay_ms(0);
SPICLOCKLAT = 1;
delay_ms(0);
SPICLOCKLAT = 0;
SPIOUTLAT = 0;
return 0; 
}
//
//
//
// see comments in writespimanual function
unsigned char ReadSPIManual (void) {
unsigned char result = 0x00;
SPICLOCKLAT = 0;
SPIOUTLAT = 0;
SPICLOCKLAT = 0;
delay_ms(0);
SPICLOCKLAT = 1;
delay_ms(0);
if (SPIINPORT)
result |= 0x80;
SPICLOCKLAT = 0;
delay_ms(0);
SPICLOCKLAT = 1;
delay_ms(0);
if (SPIINPORT)
result |= 0x40;
SPICLOCKLAT = 0;
delay_ms(0);
SPICLOCKLAT = 1;
delay_ms(0);
if (SPIINPORT)
result |= 0x20;
SPICLOCKLAT = 0;
delay_ms(0);
SPICLOCKLAT = 1;
delay_ms(0);
if (SPIINPORT)
result |= 0x10;
SPICLOCKLAT = 0;
delay_ms(0);
SPICLOCKLAT = 1;
delay_ms(0);
if (SPIINPORT)
result |= 0x08;
SPICLOCKLAT = 0;
delay_ms(0);
SPICLOCKLAT = 1;
delay_ms(0);
if (SPIINPORT)
result |= 0x04;
SPICLOCKLAT = 0;
delay_ms(0);
SPICLOCKLAT = 1;
delay_ms(0);
if (SPIINPORT)
result |= 0x02;
SPICLOCKLAT = 0;
delay_ms(0);
SPICLOCKLAT = 1;
delay_ms(0);
if (SPIINPORT)
result |= 0x01;
SPICLOCKLAT = 0;
return result;
}
//

dandynstuff
User
Posts: 14
Joined: Mon 2017-03-13 18:51

Re: Unreliable Reset of VS1053

Post by dandynstuff » Sat 2017-05-20 15:04

Well thank you all for the great help. Finally got around to looking at the problem again. At the moment I have the impression that probably the Arduino-board is soldered baddly and has a loose contact, in any case at the moment I can not get the VS1053 to malfunction anymore since I wiggled the chip a bit so it doesn't seem to be a software-problem :D

Post Reply

Who is online

Users browsing this forum: No registered users