VLSI1063 hangs during MP3 encoding

Writing software for systems that use VLSI Solution's devices as slave codecs to a host microcontroller.
lauba1
User
Posts: 17
Joined: Wed 2017-01-11 9:26

VLSI1063 hangs during MP3 encoding

Post by lauba1 » Tue 2017-12-12 17:21

Hello,

we have strange problem with VLSI 1063 MP3 encoding mode. So sometimes the vlsi is recording properly, but sometimes is hangs and put all time the same data to the file what will be show in the attached file.
Chip is working in our hardware design. We examined supply voltages for fluctuactions and didn't catch any important voltages drop. Each decupling capacitors for VLSI is placed for 470 nF. The connection between main uc and VLSI is about 1,5 cm.

Now software :
here is our init function :

Code: Select all

int VSTestInitHardware(void)
{
	/*Configure Chip Select Pin for command and data to high logic level */
	HAL_GPIO_WritePin(VLSI_CS_GPIO_Port, VLSI_CS_Pin, GPIO_PIN_SET);
	HAL_GPIO_WritePin(XDCS_GPIO_Port, XDCS_Pin, GPIO_PIN_SET);
	/*Configure GPIO pin Restet and chip select from SD CARD to high logic level */
	HAL_GPIO_WritePin(GPIOA, XRESET_Pin|SD_CS_Pin, GPIO_PIN_SET);
	/*Hardware RESET*/
	HAL_GPIO_WritePin(GPIOA, XRESET_Pin, GPIO_PIN_RESET);
	/*some delay*/
	HAL_Delay(70);
	/*End Hardware RESET*/
	HAL_GPIO_WritePin(GPIOA, XRESET_Pin, GPIO_PIN_SET);
	/*some delay*/
	HAL_Delay(10);

	return 0; /*Hw init success*/
}

Code: Select all

int VSTestInitSoftware(void)
{
	/* Start initialization with a dummy read, which makes sure our
	   microcontoller chips selects and everything are where they
	   are supposed to be and that VS10xx's SCI bus is in a known state. */
	   
	   (void)ReadSci(SCI_MODE);
	   
	/* First real operation is a software reset. After the software
	   reset we know what the status of the IC is. You need, depending
	   on your application, either set or not set SM_SDISHARE. See the
	   Datasheet for details. */
	   
	   WriteSci(SCI_MODE, SM_SDINEW | SM_RESET);
	   
	  /* A quick sanity check: write to two registers, then test if we
	     get the same results. Note that if you use a too high SPI
	     speed, the MSB is the most likely to fail when read again. */
	     
	  WriteSci(SCI_AICTRL1, 0xABAD);
	  WriteSci(SCI_AICTRL2, 0x7E57);
	  
	  if (ReadSci(SCI_AICTRL1) != 0xABAD || ReadSci(SCI_AICTRL2) != 0x7E57)
	  {
	    /*printf("There is something wrong with VS10xx SCI registers\n");*/
	    return 1;
	  }
	  WriteSci(SCI_AICTRL1, 0);
	  WriteSci(SCI_AICTRL2, 0);

	/* Set the clock. Until this point we need to run SPI slow so that
	   we do not exceed the maximum speeds mentioned in
	   Chapter SPI Timing Diagram in the Datasheet. */
	WriteSci(SCI_CLOCKF,HZ_TO_SC_FREQ(12288000) | SC_MULT_53_40X | SC_ADD_53_15X);
	/* Now when we have upped the VS10xx clock speed, the microcontroller
	   SPI bus can run faster. Do that before you start playing or
	   recording files. */

	/* Set up other parameters. */
	WriteVS10xxMem(PAR_CONFIG1, PAR_CONFIG1_AAC_SBR_SELECTIVE_UPSAMPLE);

	/* Set volume level at -6 dB of maximum */
	WriteSci(SCI_VOL, 0x0c0c);

	/* Now it's time to load the proper patch set. */
	LoadPlugin(plugin, sizeof(plugin)/sizeof(plugin[0]));
	
	/* We're ready to go. */
	return 0;
}
Here is our recording function, to noticed the problem into file we need to use brute force method to end the file. Due to we can see how is looking the problem.

Code: Select all


u_int16 ReadSci(u_int8 addr)
{
	uint8_t u8InHigh;
	uint8_t u8InLow;
	while(!HAL_GPIO_ReadPin(DREQ_GPIO_Port,DREQ_Pin))	/*Check if DREQ is low - if is low can't  */
	{
		; /*wait*/
	}
	VsSelectChip();
	SpiTransmitReceive(VS_READ_COMMAND);
	SpiTransmitReceive(addr);
	u8InHigh  = SpiTransmitReceive(0xFF); /* High Byte */
	u8InLow   = SpiTransmitReceive(0xFF); /* Low Byte */
	VsDeselectChip();
	return ((uint16_t)u8InHigh<<8) + u8InLow;
}

Code: Select all

uint8_t VS1063RecordFileConst(FIL outFP)
{
	if(u16Sample == 22000)
		u16Sample = 22050;

	/*Open the file*/
	if(s_ResultObject == FR_OK)
	{
		u16IncString ++;
		NameOfFile[3] = (u16IncString/100) + '0';
		NameOfFile[4] = (u16IncString/10)  + '0';
		NameOfFile[5] = (u16IncString%10)  + '0';
		s_ResultObject = f_open (&outFP,(TCHAR*)NameOfFile , FA_WRITE | FA_OPEN_ALWAYS);
		if(s_ResultObject == FR_OK)
		{
			s_ResultObject = f_lseek(&outFP, 0);
			s_ResultObject = f_truncate(&outFP);
		}
	}

	uint32_t u32WordsWaiting = 0;
	uint32_t u32HowManyBytesSaved = 0;
	uint32_t u32FileSize = 0;
	state = 0;
	StopKeyPushed = 0;


	/* This clock is high enough for both Ogg and MP3. */
	WriteSci(SCI_CLOCKF,HZ_TO_SC_FREQ(12288000) | SC_MULT_53_50X | SC_ADD_53_00X);
	/* The serial number field is used only by the Ogg Vorbis encoder,
	and even then only if told to used the field. If you use to
	encode Ogg Vorbis, use a randomizer or other function that creates
	a different serial number for each file. */
	WriteVS10xxMem32(PAR_ENC_SERIAL_NUMBER, 0x87654321);
	/* Example definitions for MP3 recording.
	For best quality, record at 48 kHz.
	If you must use CBR, set bitrate to at least 160 kbit/s. Avoid 128 kbit/s.
	Preferably use VBR mode, which generally gives better results for a
	given bitrate. */
	WriteSci(SCI_RECRATE, u16Sample );
	WriteSci(SCI_RECGAIN, 1024); /* 1024 = gain 1 = best quality */
	WriteSci(SCI_RECMODE, RM_63_FORMAT_MP3 | RM_63_ADC_MODE_RIGHT);

	if (u8Mode)
	{
		/* Example of VBR mode */
		WriteSci(SCI_RECQUALITY, RQ_MODE_VBR | RQ_MULT_1000 | u16KbpsValue); /* ~160 kbps */
	}
	else
	{
		/* Example of CBR mode */
		WriteSci(SCI_RECQUALITY, RQ_MODE_CBR | RQ_MULT_1000 | u16KbpsValue); /*  160 kbps */
	}
	HAL_GPIO_WritePin(RED_LED_GPIO_Port,RED_LED_Pin,RESET); /*Turn on diode*/
	WriteSci(SCI_MODE, ReadSci(SCI_MODE) | SM_LINE1 | SM_ENCODE);
	WriteSci(SCI_AIADDR, 0x0050); /* Activate recording! */

	it_u32RecordStop30Minut = __30_MINUTES + 2;

	/* Main loop */
	while (state < 3)
	{
	/*Check if recorder is working*/
	/* See if power button is pressed = end recording  OR if the watchdog from voice detected is not feed on the time*/
		if( (common_sObjectFlags.u8SwichOffPressed == SET) )
		{
			StopKeyPushed = 1;
		}
		else if(it_u32RecordStop30Minut == 2u)
		{
			StopKeyPushed = 1;
			it_u32RecordStop30Minut = 1;
		}

		if (StopKeyPushed && !state)
		{
			f_close (&outFP );
			return 1;
//			state = 1;
//			static uint16_t u16ReadSCI = 0;
//			u16ReadSCI =  ReadSci(SCI_MODE);
//			WriteSci(SCI_MODE, u16ReadSCI | SM_CANCEL); //Request to stop recording
		}

		/* See how many 16-bit words there are waiting in the VS1063 buffer */
		u32WordsWaiting = ReadSci(SCI_RECWORDS);
		/* If user has requested stopping recording, and VS1056 has
		stopped recording, proceed to the next state. */
		/*After a while (typically less than 100 ms), SM_CANCEL will be cleared by VS1063a*/
		if (state == 1 && !(ReadSci(SCI_MODE) & SM_CANCEL) )
		{
			state = 2;
		}

		if (u32WordsWaiting > 0)
		{
			uint32_t u32LocalCnt;
			uint32_t u32WordsToWrite;
			u_int8 *rbp = recBuf;
			u32WordsToWrite = min(u32WordsWaiting, REC_BUFFER_SIZE/2);
			for (u32LocalCnt = 0; u32LocalCnt<u32WordsToWrite; u32LocalCnt++)
			{
				u_int16 w = ReadSci(SCI_RECDATA);
				*rbp++ = (u_int8)(w >> 8);
				*rbp++ = (u_int8)(w & 0xFF);
			}
			f_write (&outFP, (const void*)recBuf,(UINT)2*u32WordsToWrite,(UINT*) &u32HowManyBytesSaved);
			u32FileSize += 2*u32WordsToWrite;
		}
		else
		{
			/* The following read from SCI_RECWORDS may appear redundant.
			But it's not: SCI_RECWORDS needs to be rechecked AFTER we
			have seen that SM_CANCEL have cleared. */
			if ( (state == 2) && (!ReadSci(SCI_RECWORDS)) )
			{
				state = 3;
			}
		}


	}
	HAL_Delay(10);
	/* We need to check whether the file had an odd length.
	That information is available in the MSB of PAR_END_FILL_BYTE.
	In that case, the 8 LSB's are the missing byte, so we'll add
	it to the output file. */
	u_int16 lastByte;
	uint8_t u8LastByteToSaveToSd = 0;
	lastByte = ReadVS10xxMem(PAR_END_FILL_BYTE);
	if (lastByte & 0x8000U)
	{
		u8LastByteToSaveToSd = (uint8_t)(lastByte&0xFF);
		f_write (&outFP, (const void*)&u8LastByteToSaveToSd,(UINT)1,(UINT*) &u32HowManyBytesSaved);
	}
	else
	{

	}
	f_close (&outFP );
	return 1;
}

In the attachments are mp3 file with problem.
Attachments
NOv001.mp3
(908.51 KiB) Downloaded 62 times
NOv001.mp3
(72.9 KiB) Downloaded 64 times

lauba1
User
Posts: 17
Joined: Wed 2017-01-11 9:26

Re: VLSI1063 hangs during MP3 encoding

Post by lauba1 » Wed 2017-12-13 21:22

Hello if someone has any question to clarify the problem please ask. For us is a tricky question to answer, because in 7 for 10 recording the module is working fine and in 3 cases is a problem with communication between uC and VLSI. :)

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

Re: VLSI1063 hangs during MP3 encoding

Post by pasi » Mon 2017-12-18 12:34

Because you are always receiving the same word from reading HDAT0, it looks like the encoding has ended in one way or another.

Some things to check when this happens:
- What does SCI_MODE contain? Is SM_ENCODE still set in SCI_MODE?
- Contents of SCI_AUDATA, SCI_STATUS, SCI_AICTRL0..3?

What's your SCI speed?
Visit https://www.facebook.com/VLSISolution VLSI Solution on Facebook

lauba1
User
Posts: 17
Joined: Wed 2017-01-11 9:26

Re: VLSI1063 hangs during MP3 encoding

Post by lauba1 » Tue 2017-12-19 16:15

SCI speed = 4,5 Mhz
Here is our registers value :
SCI_MODE = 101100000000000
SCI_AUDATA = 101110111000000
SCI_STATUS = 1100000
SCI_AICTRL0 = 101011000100010
SCI_AICTRL1 = 10000000000
SCI_AICTRL2 = 1111111111111111
registerVLSI.JPG
registerVLSI.JPG (30.56 KiB) Viewed 1157 times
We noticed that if in function VSTestInitSoftware when we want to write to SCI_MODE this instruction below:

Code: Select all

 WriteSci(SCI_MODE, SM_SDINEW | SM_RESET);
we read value like this:
SCI_MODE = 100000000000

so SM_SDINEW value is not set ok.

lauba1
User
Posts: 17
Joined: Wed 2017-01-11 9:26

Re: VLSI1063 hangs during MP3 encoding

Post by lauba1 » Wed 2017-12-20 12:03

Here is our connection between uC nad VLSI.
VLSI connection.JPG
VLSI connection.JPG (52.88 KiB) Viewed 1146 times

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

Re: VLSI1063 hangs during MP3 encoding

Post by pasi » Wed 2017-12-20 13:47

lauba1 wrote:
Tue 2017-12-19 16:15
We noticed that if in function VSTestInitSoftware when we want to write to SCI_MODE this instruction below:

Code: Select all

 WriteSci(SCI_MODE, SM_SDINEW | SM_RESET);
we read value like this:
SCI_MODE = 100000000000
That seems like the correct value to read (0x0800).

Also, the register values you list seem ok. SM_ENCODE is set, so the firmware should return a different value for each read from SCI_HDAT0. Because it doesn't, there is something strange going on.

Is CVDD 1.8V and stable?
Visit https://www.facebook.com/VLSISolution VLSI Solution on Facebook

lauba1
User
Posts: 17
Joined: Wed 2017-01-11 9:26

Re: VLSI1063 hangs during MP3 encoding

Post by lauba1 » Thu 2017-12-21 12:37

CVDD 1.8V checked and the rest voltages all looks ok... so we are looking for the problem 2 months and still we are at the same point. Maybe try to switch to uart? and in observation the problem occurs after some time of recording or only in the situation when we want to end the recording.

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

Re: VLSI1063 hangs during MP3 encoding

Post by pasi » Thu 2017-12-28 13:45

When the issue appears, do you still get the monitoring sound from the analog outputs?

Have you double-checked you SPI clock polarity?
Visit https://www.facebook.com/VLSISolution VLSI Solution on Facebook

KtroniX
User
Posts: 6
Joined: Tue 2017-01-31 12:44

Re: VLSI1063 hangs during MP3 encoding

Post by KtroniX » Mon 2018-01-08 15:16

Hello

From hardware point of view. I examined oscillator, start up and stable operation.
20171222_132954.jpg
oscillator
20171222_132954.jpg (746.45 KiB) Viewed 1044 times
Supply voltage stability for VLSI:
DC mode:
20171223_161824.jpg
dc_mode_psu
20171223_161824.jpg (826.02 KiB) Viewed 1044 times
AC mode:
20171223_162331.jpg
ac_mode_psu
20171223_162331.jpg (927.83 KiB) Viewed 1044 times
AC mode supply zoom:
20171223_162424.jpg
ac_mode_psu_zoom
20171223_162424.jpg (735.4 KiB) Viewed 1044 times
arround 10% p-p of core supply voltage at worst power loop. According to datasheet (1,85-1,7)/1,8 = 8,3%! Could it be possible that VLSI doesn't withstands those oscillations on power rails? Each power pin is decouples with its own 100nF capacitor. Oscilations directly on caps are negligible.
20171223_162926.jpg
ac_mode_time_zoom
20171223_162926.jpg (917.16 KiB) Viewed 1044 times
Oscillation frequency about 25MHz.

We are going to do small check with additional connections on power lines.

Layout routing on 35um Cu, 2 layer.
routing.png
layout_routing
routing.png (460.74 KiB) Viewed 1044 times


Would be also nice if some could take a look on this.
Last edited by KtroniX on Mon 2018-01-08 15:33, edited 1 time in total.

KtroniX
User
Posts: 6
Joined: Tue 2017-01-31 12:44

Re: VLSI1063 hangs during MP3 encoding

Post by KtroniX » Mon 2018-01-08 15:24

Further measurement specification.
Voltage oscillation captured between points:
meas_points.png
measurement_points
meas_points.png (370.57 KiB) Viewed 1044 times
Saleae SPI log. (SPI CLK 2MHz)
failed.png
saleae
failed.png (77.67 KiB) Viewed 1044 times
Thank you for data analysis.

Post Reply