TMS570LS3137ZWT configuring FPGA over SPI

Martin Zeman

Hi,

I've been using the SPI interface to load a design into an Altera Cyclone IV E fpga. I've converted a .sof file into a compressed .rbf file. Then using a hex editor I've converted this .rbf file into an array of bytes which lookes like this :

const unsigned char configData[728076] =
{
    0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 
    0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 
    0x6A, 0xF7, 0xF7, 0xF7, 0xF7, 0xF7, 0xF7, 0xF3, 0xFB, 0xF3, 0xF9, 0xFB, 0xF1, 0xF1, 0xF9, 0xF9, 
...
...

Previously I've been using a simpler design which only had 514231 bytes. I've tested it and it worked fine. Byt now after replacing the design with the new one (728076 bytes long) something went wrong. Everything still works also fine when I load the design into the fpgawith a usb blaster then and I'm able to read the correct values from fpga's registers. Only when I load the new design over SPI is when it fails and I read gibberish. The thing is that the configuration seems to be working (CONF_DONE goes high). Here's the code that I'm using to load the design into the fpga:

void fpgaConfig(void)
{
	int i;
	const int length = 728076;
	uint16_t temp;
	spiDAT1_t dataConfig;

	gioSetBit(spiPORT1, SPI_PIN_SOMI, 0);	// nConfig low
	delay(0xffff);	// wait
	gioSetBit(spiPORT1, SPI_PIN_SOMI, 1);	// nConfig high
	while(gioGetBit(spiPORT1, SPI_PIN_ENA) == 0);	// wait until nStatus is high

	spiSetFunctional(spiREG1, spiREG1->PC0 | (1U << SPI_PIN_SOMI));	// set nCONFIG as SPI pin

	dataConfig.CSNR = 0;
	dataConfig.CS_HOLD = 0;
	dataConfig.DFSEL = SPI_FMT_0;
	dataConfig.WDEL = 0;
	//length = sizeof(configData);
	for(i = 0; i < length; i++)
	{
		temp = configData[i];
		spiTransmitData(spiREG1, &dataConfig, 1, &temp);
	}

	while(gioGetBit(spiPORT2, SPI_PIN_CLK) == 0);	// wait until CONF_DONE is high
	while(gioGetBit(gioPORTB, 7) == 0);	// wait until INIT_DONE is high
}

Any ideas why could this be happening?

over 11 years ago

0 Anthony F. Seely over 11 years ago

TI__Guru 69070 points

Martin,

Hi, sorry no ideas. Don't have much experience w. Altera at all - I've used mainily Xilinx parts.

On the Xilinx parts, the bitstreams are heavily protected w. CRC and if you get the 'DONE' signal this usually is a solid indicator that you have correctly configured your FPGA. Would assume Altera is the same but you'd need to check w. Altera's docs / support folks.

If it is the case, and your config w. the download cable using the same file works but you can't talk on the EMIF when you configure over SPI, the only thing I can think of is this: could you somehow be 'flushing' the configuration by accident *after* done goes high. ie. if there is an 'init' type pin that resets the FPGA could you be pulling this inadvertently?

0 Martin Zeman over 11 years ago in reply to Anthony F. Seely

Intellectual 820 points

So things have moved forward a bit. There was a trivial miskate that caused me not to pull the nCONFIG signal low to begin configuration. So it's working over SPI now when loading from MCU's flash memory. Now I'm trying to configure it like this:
PC -> TCP -> MCU -> SPI -> FPGA. And I have a problem that the configuration doesn't finish. All the packets were sent, received and written into the FPGA over SPI but the CONF_DONE doesn't go high (signalling successful configuration). I'm not sure but it seems to me that this should not be caused by the relative slowdown (delays between SPI writes) when compared to the pure FLASH/SPI solution. Am I right?

0 Anthony F. Seely over 11 years ago in reply to Martin Zeman

TI__Guru 69070 points

Right, I think this means that either the config wasn't completed (like some data was missed), or there was a bit error, or something like this. Unfortunately I'm not sure how to debug this because you're sending compressed data to that FPGA, and you need to narrow down to find the error.

Maybe you can do something like check the last couple bytes sent over the SPI (with an analyzer or scope) and check this against the bit blaster. That would let you at least know you got to the end of the file.

0 Martin Zeman over 11 years ago in reply to Anthony F. Seely

Intellectual 820 points

So it turns out that the fault was in my implementation of the TCP server which caused the data sent over the spi to be corrupted. It's working now. Thanks

Arm-based microcontrollers

Arm-based microcontrollers forum

TMS570LS3137ZWT configuring FPGA over SPI