VS1053: what to do with XDCS in SCI?

[zulunation]

Hello,

I am using VS1053 chip.
I have read the datasheet but can't find some information.

I am using chip in new mode and SDISHARED is 0.
So I need to use XDCS (which is BSYNC now) when sending data.
But what should I do with XDCS when sending SCI data? When reading and writing registers?
There is no information in datasheet about that.

I have more questions.

1.
Why data synchronization (BSYNC and in new mode it is XDCS) are needed?
The data transfer starts from SPI clock so SCLK is the bit synchronization signal.
Why we need additional signal?
This BSYNC(XDCS) signal can be not used by setting SDI_SHARED to 1.
So MCU must ensure data synchronization. But what does that mean?
SPI always has CLK signal which synchronizes data.


2. Here is quote from datasheet

If SM_SDISHARE is 1, pin XDCS is not used, but the signal is generated internally by inverting XCS.

What signal is generated by inverting XCS?
Does that mean that XCS must be high in SDI?

This is done for VS1053 to distinguish SCI from SDI mode?
in SCI XCS is low
in SDI XCS is high?

[pasi]

Do you have NEWMODE set? If yes, then both SCI and SDI use the same SPI CLK, SPI SI, and SPI SO pins.

If you also have SDISHARED set, then xCS low will cause the SPI transaction go to SCI, and xCS high will cause the SPI transaction go to SDI.

If SDISHARED is not set, the xCS low causes the SPI transaction go to SCI, xDCS low causes the SPI transaction go to SDI, if both are high the transaction does not go to either, and if both are low that's undefined -- probably both try to interpret the data.

So, with NEWMODE=1 and SDISHARED=0, have xCS=0, xDCS=1 for SCI transactions, and xCS=1, xDCS=0 for SDI transfers.

1. Why data synchronization (BSYNC and in new mode it is XDCS) are needed?
The data transfer starts from SPI clock so SCLK is the bit synchronization signal.

A glitch in the SPI clock would make all SDI data shifted by 1 bit, and the decoders expect the data to be byte-synchronized. Occasional assertion and deassertion of a chip select signal restores byte-level synchronization.

Also, SCI transactions start with a command and address byte. xCS tells when the transaction starts and ends.

[zulunation]

Hello,

Thanks for reply.
I understood how to handle xdcs.

I have another question.
I am working in SCI mode. After the last SPI clock DREQ goes low to indicate busy state.
My CPU is so fast that after I set XCS high I check DREQ and it is still high. So my software is pushing new data.
I didn't found any time in datasheet. Time between last SPI clock and DREQ low.
I have attached a picture and marked red this time.
It is not specified in datasheet.
I think some delay must be inserted before reading DREQ state.

[pasi]

Which SCI registers are you reading or writing?

The register table in chapter 9.6 of the vs1053 datasheet gives the expected processing times for each SCI register (read or write, depending).

DREQ going down is an indication that the SCI transaction was detected. The latency of DREQ going low varies a bit, because other interrupts may be in service at a time. If you know you're not going to write / read SCI registers too quickly, you don't need to check DREQ for SCI transactions. This also allows you to read and write SCI registers while DREQ is low due to the SDI FIFO being full.

Assuming 4.0x clock, the whole SCI interrupt service takes minimum 80 CLKI cycles, about 1.6us.

The SCI clock should be internal clock divided by 7. Assuming 4.0x clock, this is 7Mbit/sec. If the CLKI/7 restriction is fulfilled, a SCI transaction takes 32 bits and 7 CLKI cycles per bit = 224 clock cycles total. SCI transactions to/from most registers thus do not need any extra wait time, even with other interrupts active.

[zulunation]

Hello pasi,

Thanks for explanation!

The latency of DREQ going low varies a bit
not going to write / read SCI registers too quickly

The problem is that I am working at the CLKI = 4.5*12.288 MHz.
And my CPU instruction clock is 20ns.

Currently I see that after last SPI clock (SCI write) DREQ goes low after 500 ns.
My CPU manages to check that DREQ is high before DREQ goes low and pushes another
data to register.
So it is not a good idea to check DREQ status immediately after SPI finishes.

So I decided to modify my algo.
I am developing universal driver which may be running on different CPU's with different speed.

I have attached the picture.
X time is time between last SPI clock and DREQ goes low. Ii is unknown.
T is time during which DREQ stays low. It is known from table.
So if I wait T time after last SPI clock and then wait for DREQ goes high it should work.
As X time will never be longer than T after waiting for T time i will see that DREQ is low and wait until it goes high.
Or DREQ will be high already after waiting for T time.

Am I correct?

[Hannu]

Many microcontrollers have HW to detect pin changes.

One way would be arm detection HW for falling edge of DREQ, and then check if it is falled after SPI transaction or wait for it.
Then you can wait it to rise or timeout and try to do something smart.

This requires some MCU specific part and some MCU independent part. And that can make maintaining little bit a hassle.

I wrote something horrible to show the algo how would I do that If I couldn't make assumptions about clocks.

Code: Select all

spiWord SpiStuff(spiWord w) {
	unsigned to = SPI_TIMEOUT;
	SpiLowerCS();
	SpiSendThis(w);
	w = SpiWhatReceived();
	while(to-- && DREQIsHigh()) {
		SpiRiseCS();
	}
	if (!to) {
		/* OH NO! */
	}
	to = SPI_TIMEOUT;
	while (to-- && DREQIsLow()) {
		/* VS1053 is processing */
	}
	if (!to) {
		/* OH NO NOT AGAIN TIMEOUT! */
	}
	return w;
}

[pasi]

If the CLKI/7 restriction is fulfilled, a SCI transaction takes 32 bits and 7 CLKI cycles per bit = 224 clock cycles total. SCI transactions to/from most registers thus do not need any extra wait time, even with other interrupts active.

The main point of this note is that you can start the next SCI transaction before the previous one has fully finished servicing. This is especially useful when you read the encoded data through SCI_HDAT0. You don't want to wait extra between the SCI reads.

The firmware gets the next interrupt only at the end of the next SCI transaction (or the next word for SCI multiple write). If you're writing to SDI next, then you need to be guarded.

Maybe you can make separate functions for these multiple-word reads from the same register (and writes, but multiple writes to the same register can be performed in a single SCI transaction).