SPI Flash takes too long to respond to commands

Benjamin Valentin

Other Parts Discussed in Thread: TM4C123GH6PM

Hi,

I'm trying to access an AT25DF041A SPI Flash chip on the tm4c123gh6pm.

As the chip requires the Chip Select pin to be low during a multi-byte command, I've configured it as GPIO and toggle it manually.

To read a page I do

void read_page(uint32_t address, uint8_t *data, uint8_t len) {
	spi_tx_start();
	ROM_SSIDataPut(SSI3_BASE, CMD_FREAD);
	ROM_SSIDataPut(SSI3_BASE, (address >> 16) & 0xff);
	ROM_SSIDataPut(SSI3_BASE, (address >>  8) & 0xff);
	ROM_SSIDataPut(SSI3_BASE, (address >>  0) & 0xff);
	ROM_SSIDataPut(SSI3_BASE, 0x0); // dummy

	ROM_SysCtlDelay(1000); // ugly hack

	spi_rx_flush();

	while (len-- > 0) {
		ROM_SSIDataPut(SSI3_BASE, 0x0);
		ROM_SSIDataGet(SSI3_BASE, (uint32_t*) data++);
	}

	spi_tx_end();
}

spi_tx_start/spi_tx_end will set the CS pin low/high, to make sure the SPI transfer is complete, the end function also does busy wait to make sure the SPI transfer finished before deasserting CS

while (ROM_SSIDataGetNonBlocking(SSI3_BASE, 0));

To clear the rx buffer (here might be stuff in there from writing the command and the address) I do

void spi_rx_flush(void) {
    while (ROM_SSIDataGetNonBlocking(SSI3_BASE, 0));
}

Now the problem is that there seems to be a delay between writing the command and address and the Flash Chip actually answering me with data - without the SysCtlDelay() I get

2014-10-28 23:46:54,715 - INFO # [0] 0 0 0 0 0 fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe 
2014-10-28 23:46:54,732 - INFO # [40] 0 0 0 0 fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe 
2014-10-28 23:46:54,749 - INFO # [80] 0 0 0 0 fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe 
2014-10-28 23:46:54,766 - INFO # [c0] 0 0 0 0 fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe 
2014-10-28 23:46:54,783 - INFO # [100] 0 0 0 0 fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe 
2014-10-28 23:46:54,800 - INFO # [140] 0 0 0 0 fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe 
2014-10-28 23:46:54,817 - INFO # [180] 0 0 0 0 fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe

SPI reads 0 because the chip hasn't answered yet, everything is shifted to the right. With the artificial delay on the host, the data is correct:

2014-10-28 23:48:27,108 - INFO # [0] fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef 
2014-10-28 23:48:27,125 - INFO # [40] fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef 
2014-10-28 23:48:27,142 - INFO # [80] fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef 
2014-10-28 23:48:27,160 - INFO # [c0] fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef 
2014-10-28 23:48:27,177 - INFO # [100] fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef 
2014-10-28 23:48:27,194 - INFO # [140] fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef 
2014-10-28 23:48:27,211 - INFO # [180] fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef 
2014-10-28 23:48:27,229 - INFO # [1c0] fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef 
2014-10-28 23:48:27,246 - INFO # [200] fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef 
2014-10-28 23:48:27,263 - INFO # [240] fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef 
2014-10-28 23:48:27,280 - INFO # [280] fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef 
2014-10-28 23:48:27,298 - INFO # [2c0] fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef 
2014-10-28 23:48:27,315 - INFO # [300] fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef 
2014-10-28 23:48:27,332 - INFO # [340] fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef 
2014-10-28 23:48:27,350 - INFO # [380] fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef 
2014-10-28 23:48:27,366 - INFO # [3c0] fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef fe ed fe fe de ad be ef

What is the proper way to fix this?

I can't ask the Flash Chip wheather it's ready, since doing so would consitute another command - and I'm just waiting for a response for the command I just gave it.

over 11 years ago

0 Amit Ashara over 11 years ago

TI__Guru**** 244440 points

Hello Benjamin,

One thing we have done in the past with such an access is that for the Flash chip to respond it has a finite number of clocks that it will not transmit before sending the bits. These finite number of clocks for it to start is documented by the Flash IC Vendor based on the command used to access it.

For these many byte reads from the Flash we would flush the data out and then expect the data to be read out correctly, without the aritifical delay. This of course requires the Non Block Read to be replaced by a Blocking Read

Regards

Amit

0 Benjamin Valentin over 11 years ago in reply to Amit Ashara

Prodigy 220 points

That's strange since the data sheet doesn't seem to mention additional clock cycles, it only says

After the three address bytes (and the one don't care byte if using opcode 0Bh) have been
clocked in, additional clock cycles will result in serial data being output on the SO pin. The data
is always output with the MSB of a byte first.

Could it be that my SPI clock is running too fast? I configure it with

    ROM_SSIConfigSetExpClk(SSI3_BASE, ROM_SysCtlClockGet(), SSI_FRF_MOTO_MODE_0, SSI_MODE_MASTER, ROM_SysCtlClockGet() / 20, 8);

0 Michel Raabe over 11 years ago in reply to Benjamin Valentin

Intellectual 500 points

Hey Benjamin,

well given the 'CMD_FREAD' is the 0x0B (fast Read) Opcode for the Eeprom, i don't see a problem of your SSI being too fast. Since you divide your System Clock, which can't really be over 100MHz i assume, by 20 as your SSI Clock.

And that Flash can take up to 70MHz. I do highly doubt TI offers overclocked 1.4GHz versions of the TivaC Series.

However, i believe Amits solution with simply using the 'Blocking' option of reading the SSI communication should help. I still wonder why the Flash producer didn't offer insight into the delay between sent command and output data..

Sincerely,

Michel

0 Benjamin Valentin over 11 years ago in reply to Michel Raabe

Prodigy 220 points

I'm doing a spi_rx_flush_n(4); now

void spi_rx_flush_n(uint32_t skip) {
	while (skip--) {
		ROM_SSIDataPut(SSI3_BASE, 0);
		ROM_SSIDataGet(SSI3_BASE, 0);
	}
}

where 4 is an experimentally derived value. I'm not particular comfortable with such magic number, but it works.

Might have to change that for the liquid cooled version ;)

0 Amit Ashara over 11 years ago in reply to Benjamin Valentin

TI__Guru**** 244440 points

Hello Benjamin,

The answer is in the data sheet from the vendor. For 3 Address Byte+1 Don't Care Byte the Flash will send the data. So basically you need to always flush out 4 bytes irrespective of the speed.

Regards

Amit

Arm-based microcontrollers

Arm-based microcontrollers forum

SPI Flash takes too long to respond to commands