S32K3: Data Flash read timing for 1 byte

[nkarthik]

hi NXP Team,

I would like to understand the Data Flash read timing for 1 byte for NVM read cycle operation in the S32K322 Micro.I am not able to find in the data sheet clearly.

[lukaszadrapa]

Hi @nkarthik 

If data are already available in a buffer, the data are returned to crossbar switch in single cycle (zero wait states):

If data are not available in the buffer, physical flash array needs to be read. The flash is relatively slow, so some wait states are needed. The number of wait states depends on system frequency (it is the same as flash frequency shown on the screenshot below):

If your device runs at 160MHz, 4 additional clocks are needed to read one flash line.

Of course, enabled instruction and data cache will significantly improve the performance.

Regards,

Lukas

[nkarthik]

Hi Lukas,

Thank you. Just for Calculation, For Example, 20bytes of data,& Flash Frequency 160Mhz,

Then Flash Read timing is

=20 * (1/Flash Frequency) * No of CLK Cycles required for Read.

=20*(1/160Mhz) *4

= 0.5us

Please confirm my understanding.

[lukaszadrapa]

Well, it's not as simple as that. Similar simple calculations were possible on very old devices (getting back to my nostalgic memories about 8051) but modern devices are not deterministic like that. Due to features increasing the performance (flash line buffer / flash mini-cache, prefetching, data cache on core) and other influence (like crossbar switch, other bus masters), you can get different results based on current conditions. Even ARM does not provide detailed instruction timing.

If you are going to read more bytes which are stored sequentially in the flash, just the first access will take more time due to flash wait states. Then corresponding flash line will be already loaded in the buffer, so other bytes can be read in single cycle... Then it depends if all the bytes are in single flash line only, on prefetching etc.

Generally, the best and simplest way to check timing of some critical code sections is to do that empirically - just toggle a pin before/after execution of such code and measure the pulse by an oscilloscope.

Regards,

Lukas