Using VS1010D as a spi slave

[Henrik]

Your transmission has very little sense.

Code: Select all

0001 0010 0011 0100 0x1234 Should be
0010 0100 0001 0110 0x2416 Really is

Actually, I might have found en explanation that makes some sense. The assumptions I make are that for some reason the other end is treating bit order incorrectly (LSb first), and that the data has been shifted by one bit (by e.g. incorrect clock polarity).

Here's the reasoning. First let's quote Hannu:

Code: Select all

0001 0010 0011 0100 0x1234 Should be
0010 0100 0001 0110 0x2416 Really is

Let's shift the "Really is" bits to the left by 1 bit. We get:

Code: Select all

0100 1000 | 0010 1100

Note, the pipe character '|' marks the byte boundary.

Now, if we assume that both bytes are intepreted by the other end as LSb first and not MSb first, we have to reverse the order of bits for both bytes (e.g. 0000 0001 becomes 1000 0000):

Code: Select all

0001 0010 | 0011 0100 0x1234

There are lots of guesses and matching here, so I might be completely off with my interpretation. However, it would be very interesting to see what you would get if you would try to send e.g. all possible number codes using your current setup, i.e. 0x0001, 0x0203, 0x0405 ... 0xfeff. Then we might be able to see a pattern.

Kind regards,
- Henrik

[goncalo]

The internal clock frequency is 39Khz, and the SPI shift clk rate is 19.5Khz, this in the MASTER side. Take a look at these data:

Code: Select all

SEND (MASTER)	  	 RECV (SLAVE)
0000 0001		 0100 0000
0000 0010		 0010 0000
0000 0100		 0001 0000
0000 1000		 0000 1000
0001 0000		 0000 0100
0010 0000		 0000 0010

[goncalo]

Hi again, Many thanks for all the help that you guys gave me all this time.

So, the SPI slave is working with interruption, i reversed the data bytes and made a shift rigth of 1 bit and now i can see the bytes properly. I created a counter in the MASTER and send it through SPI1 to the slave. As you can see in the last post mine, the VSDSP is counting 1 bit before the data as actual data, that means that i am losing the most significant bit and i can confirm that in my terminal.

Gonçalo

[Hannu]

Let's see what really happens with the pins to get the timing right.

I wrote small program to dump the transitions and as the VSDSP is running 60MHz, it has plenty of time to watch the pins.

This small debugging function records 31 transitions on SPI bus and then dumps them to UART, so it should be able to detect 16 bits, but not the last XCS rise. If MOSI and SCK change different time, it detects that too and the number of bits reduces.

Code: Select all

#include <vs1010_pins.h>
#include <vo_gpio.h>
#include <vs1010c.h>
void LogicAnalyzer() {
	static u_int16 capt[32];
	u_int16 i, state = 0xffff, *p = capt;
	/* Disable SPI interrupt. We don't want that now. */
	PERIP(INT_ENABLE0_LP) &= ~INTF_SPI1;
	PERIP(INT_ENABLE0_HP) &= ~INTF_SPI1;
	/* Set pins to GPIO mode */
	GpioSetAsInput(PIN_MOSI1);
	GpioSetAsInput(PIN_SCK1);
	GpioSetAsInput(PIN_XCS1);
	GpioSetPin(PIN_MISO1, 1);
	for (i = 0; i < 32; i++) {
		while (state == (PERIP(GPIO1_IDATA) & 0x00f0)) {
			/* Wait change */
			;
		}
		state = (PERIP(GPIO1_IDATA) & 0x00f0);
		*p++ = state;
	}
	p = capt;
	for (i = 0; i < 32; i++) {
		state = *p++;
		printf("%u %u %u %u\n", ((state & (1 << 7)) >> 7),
		       ((state & (1 << 6)) >> 6),
		       ((state & (1 << 5)) >> 5),
		       ((state & (1 << 4)) >> 4));
	}
}

[goncalo]

Hi,

So after a while the connection timing starts to work as intended, but after i restart the VSDSP, it becames out of sync again. These are the outputs from the VSDSP from the program that hannu wrote.

dockligth_capture.PNG

[goncalo]

Basically, when i reset the VSDSP the problem appears and when i reset the MASTER the problem resolves itself. The problem only appears when the VSDSP is reset, not the MASTER.

[Hannu]

Unfortunately your image didn't have the XCS transitions. Or I retyped it wrong. Or it doesn't change.

I can't tell if you need to have SPI_CC_CLKPOL or SPI_CC_CLKPHASE set.

Here's what you get. The DC offset is for easier level reading.

spi.png (24.6 KiB) Viewed 838 times

[goncalo]

I tried with the SPI_CC_INV_CLKPOL and SPI_CC_INV_CLKPHASE and the problem persists. The data syncs when i restart the master, but when i restart the VSDSP the problem appears, strange.

I also dont have the jp4 connected

[goncalo]

Update: The communication is working 100% fine, the problem was the XCS1 pin, when i removed the pin from the VSDSP, after a reset the communication was working without a problem, i only have 1 slave in the system.

Many thanks for all the support.

Just one more question, is it possible to disable the messages that the VSDSP sends to the uart's when i restart the VSDSP, bellow are the messages.

dockligth_capture2.PNG (4.69 KiB) Viewed 832 times

Best regards, sincerely
Goncalo

[Hannu]

The boot messages are there. You can't remove them before software starts. Earliest point would be on after first line with SPI boot system, but then you'll need to re-init the UART.

There is a one small thing when removing the XCS pin from communication. The falling edge starts transfer and then SPI clocks in DLEN +1 bits. And after that it repeats again DLEN+1 bits and so on. Have a glitch on SCK line and your sync is lost forever.

So fix your master side of the SPI communication.

If you have software SPI, take a look at devSwSpi.c from VS1010 rom sources. There are two variants. One which is easy to read (and port to other environments) and other which is optimized for VS1010. And if yor SPI master is done with HW, sit down with your MCU's datasheet and it's development libraries and see how to make proper SPI transfer.

Because if you continue from this seems to work, you'll debug why some command through SPI fails and then everything else fails too.