[SOLVED] NOR flash read/write for SPI signal integrity mesurements

[dpaul]

My FPGA(Master) is connected to a SPI NOR Flash memory(Slave). The FPGA also has a soft CPU core. Using existing firmware for the CPU, it is currently possible to read out info such as DeviceID, ManufacturerID from the NOR flash. The existing firmware can be controlled (CPU can be instructed what to do) via an UART interface and I know how to modify the C code it to suite my needs.

Now a colleague of mine wants to measure the SPI bus signal integrity at the board level, between the FPGA and the Flash, and for that reason I have to develop some firmware for him so that SPI signals keep toggling when he is doing the measurements with oscilloscope.

My question is not how to write and read to/from the Flash.

How can I structure the firmware so that the SPI signals toggle, such that it is possible for my colleague to take measurements during SPI read and write cycles?
Is it a proper way if I give him a menu option through the UART interface to first write continuously to consecutive memory locations till the end is reached and then read everything back?

Please give your suggestions.

 

[barry]

I would think, as you suggest, you can just continuously run read and write cycles.

 

[pbernardi]

You can implement a flash dump, and read from a seleted address range. Optionally, you can make some kind of script which dump the flash in a infinite loop, for example.

For writing tests, you can write into a unused sector, and limit your tests to writing and erasing this sector. Again, loop is your friend.

For oscilloscope measurements, these measurements should be enough. From oscilloscope perspective, the tester usually does not want to test all the address and data combinations, but focus on most important ones, as timings correlations and rising and falling time.

But anyway, a single SPI access should suffice, it is enought to measure the SPI waveform most of the time if properly triggered. If you are looking for integrity signal problems, there is a good chance that once you put the probe on SPI signals, the problem is not reproducible anymore (it will depend of what kind of probe your colleague use).

 

[KlausST]

Hi,

I even would avoid the "writes". With "reads" you can do all the measurements.
(Unless you want to do eye diagram with random data)

Klaus

 

[dpaul]

Thanks everyone for those suggestions!

--- Updated Jun 1, 2023 ---

Hi,

I even would avoid the "writes". With "reads" you can do all the measurements.
(Unless you want to do eye diagram with random data)

Klaus

I think this is the best answer.
Did not occur to me before, the a read command must be issued to the slave and so the direction is from M to S. And the data read back is from S to M.

 

[KlausST]

Hi,

the a read command must be issued to the slave and so the direction is from M to S. And the data read back is from S to M.

I guess I need to clarify a bit.
SPI interface was defined is always a synchronous full duplex interface. It basicall has some signals:
* SCK: 2 state. Clock generated by the master, for synchrounous data transfer (clock out ot clock in data).
* /SS: 2 state slave select from master to salve. Individually for each slave.
* MOSI: 2 state, data from master to slave.
* MISO: 3 state, data from slave to master. HIGH-Z on each slave if the according /SS signal is inactive. Usually the MISO is immediately LOW_Z when /SS is active.

In so far it usually does not matter whether you write or read from an SPI device.

Usually....
But some SPI memory devices may work differently compared to many other SPI devices. They may keep the MISO line in HIGH-Z even if /SS is active.
To be sure: you need to read the FLASH device datasheet.

In either case: Reading from a flash is the convenient one.
* it surely uses MISO line in all three states
* It does not alter the FLASH contents.
* you may read the same address to get identical (known) data pattern.
* you may load the FLASH with pseudo-random pattern and do a sequential read to get a better quality eye diagram.

Klaus

 

[dpaul]

Thanks @KlausST
We are not targeting tests, but I will keep this in mind if the board engineer wishes to do so in the future.