PSoC1 CY8C20xx6 How does one read multi-block flash data (const data) for SPI?

[StWa_1982846]

I am working with PSoC Designer 5.4 (Windows7) on the CY8C20x66A. I have some large (~4k) image data which I store into ROM/Flash by coding them in a header file as

const unsigned char Image_X[4000] = { 0xFF, <... lots of bytes ...> };

The compiler eats this up without complaint, but when I read the data to display it, I see random hash. The display output routine is a simple pointer increment loop which transmits the image through the SPI block:

for(i=0; i<bytes; i++) {

SPI_SendTxData( *dBytes ); /* load the byte for transmit */

dBytes++; /* increment the pointer */

while( ! (SPI_bReadStatus() & SPI_SPIM_TX_BUFFER_EMPTY) );

}

Regardless of the size of the data, if the source data to this loop is in RAM, the display is correct. If the data is in Flash (i.e. const), the display shows hash. What is wrong with this? What is the workaround?

Steve

[SampathS_11]

Hello Steve,

SPI_SendTxData expects the data parameter from RAM. Hence, you should copy the flash content to RAM before invoking this function as shown below.

BYTE temp;

for(i=0; i<bytes; i++) {

        temp = *dBytes;

SPI_SendTxData( temp ); /* load the byte for transmit */

dBytes++; /* increment the pointer */

while( ! (SPI_bReadStatus() & SPI_SPIM_TX_BUFFER_EMPTY) );

}

Best regards,

Sampath Selvaraj

[StWa_1982846]

Hi Sampath,

This would have been a great solution … if it worked. Unfortunately for this processor & compiler it does not. I still get hash from somewhere (in flash I think) but not from the address requested. I also tried using the E2PROM API with equally poor results. There must be some way to force the pointer back where it belongs, e.g. turning on the address bit. I just don’t understand the inner grindings well enough for that. I would have thought this issue would be well known by now.

Steve

[SampathS_11]

Hello Steve,

Can you kindly let me know if you have tried

temp = Image_X[index];

index++;

Thanks, and regards,

Sampath Selvaraj

[StWa_1982846]

Yes,

That coding style was actually my first attempt but just tried it again. Still no good unless data is put into ram by removing the ‘const’ qualifier.

Steve

[StWa_1982846]

Sampath,

I have strong reason to believe that the PSoC1 is incorrectly pulling the data out of RAM instead of ROM, because if I run the program without powering down, right after reprogramming flash, I get a distinct stripe and speckle display, like a code map. But if I then power down and wait a minute, then power up and run the same program, the display is full of random noise. There has to be some trick to remap the addressing to the flash! How is it done???

Steve

[StWa_1982846]

I am going to try using the psoc1 readblock function, described in the TRM, pg. 41. Is there a good example for this? It would be helpful to find something written for the cy8c20xx6 or something similar.

Is there some way to get this discussion on a bit wider distribution?

Steve

[SampathS_11]

Hello Steve,

It would be very helpful to me if you can kindly attach the project, so that I can get a chance to see where things are going wrong. In case you do not want to share the project, kindly copy and paste the assembly list corresponding to the C code where the data transfer is done. Let us see if I can observe something, which results in the issue we are facing.

Best regards,

Sampath Selvaraj

[StWa_1982846 · Accepted solution]

Sampath,

I have solved the problem of reading flash data which was written at compile time, using the const declaration qualifier.

• One must use the FlashReadBlock call, defined in the flashblock library. The companion call, bFlashWriteBlock is not used in this application.

• One must compute the IDBLOCK number for each call to FlashReadBlock. The first IDBLOCK number for a data constant is equal to the address of the data divided by the block size, which is 128 in our chip.

• One must read each block one at a time into a buffer in RAM. We increment the IDBLOCK number with each call to sequentially read through the entire database.

• There does not appear to be any more direct method of reading data stored in the flash. This complicates the code required, but at least the reading is possible. There is no example written for this process in the Cypress guides. There is only a brief document showing how to write and read a single block of data with the flashblock calls.

• The compiler will not prevent one from reading data outside the bounds of what was declared. There are no protections against reading all of flash except through the flashsecurity file. However, attempts to read outside of written flash may result in a hard fault and processor hang.

Steve

[StWa_1982846]

Sampath,

I wonder if the compiler is optimizing away the essential copy from flash operation?

Steve