Boot program fails on a QSPI serial flash after a cut-off supply on a block protect sequence

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
ErFo_3086866
Level 1
Level 1

Hello,

we have a strange problem with QSPI memories interfaced with a Renesas SH7266 microcontroller.

This microcontroller has an "On-chip rom boot" that allows booting on the serial flash, and copy 8K of this flash to its internal ram, and run the loaded code that is called "loader program".

This loader program can detect the location of the code of the application and copy it and run it in the internal ram of SH7266.

The application runs in the internal ram of the μP.

In most cases, it only read QSPI accesses, all blocks are write-locked.

However, it is sometimes necessary to store flash data. To do this, the application will first unlock the write accesses, write the necessary data and lock the write blocks again.

We note that the unlocking time of the blocks takes 200mS for 30μS of writing ...

The trouble is that if we turn off the power during the unlocking cycle (BP [0: 2] = 0) and turn on the power, the "on-chip rom boot" of the μP can no longer dialogue with the QSPI.

As if it remains in an unknown state.

The only way out of this incompatible state is to restart flash intialisation by the μP and its JTAG interface.

Once done, the system runs normally again without reprogramming the flash.

It seems that the QSPI remains in a state incompatible with the SH7266 boot chip despite the total power off (no hardware reset of available flash memory on the used package).

How can we avoid this problem?

We use a Cypress S25FL256S memory in a WSON8 (without RESET ...)

Thank you for your help

Eric F

0 Likes
1 Solution

Hi Eric,

We do not recommend to program status and configuration registers frequently. They can get corrupted if a power down happens during WRR operation. Please see our application note available at: http://www.cypress.com/file/207641/download for more information.


Thanks and Regards,

Sudheesh

View solution in original post

0 Likes
5 Replies
SudheeshK
Moderator
Moderator
Moderator
250 sign-ins First question asked 750 replies posted

Hi Eric,

It is not recommended to turn off power supply during a write operation. We would like to know some more details about this issue.

1. Could you please clarify the following sentence? "We note that the unlocking time of the blocks takes 200mS for 30μS of writing"

2. Are you able to read status register from flash when this issue happens? If yes, please let us know the value.

3. What are the operations performed during flash initialization?

Thanks and Regards,

Sudheesh

0 Likes

Hi Sudheesh,

thank you very much for your answer and sorry to answer only now ... The beginning of the year is very busy.

You wrote:"It is not recommended to turn off power supply during a write operation. We would like to know some more details about this issue."

My response: Yes indeed, but we want to cover the case if a power cut arrives surreptitiously.

You: "1. Could you please clarify the following sentence? "We note that the unlocking time of the blocks takes 200mS for 30μS of writing"

My response: In fact, we write a log file in the memory which consists of saving 8 bytes each time this variable is changed over a cycle of 3 hours.

So we unlocked the write sectors using Block Protect BP [0: 2] registers before writing the 8 bytes then we re-wrap all the sectors afterwards.

Now, to avoid as much as possible the blocking phenomenon after power failure, we only unlock the sectors when we start the file and then we re-lock them at the end of the recording.

You: "2. Are you able to read status register from flash when this issue happens? If yes, please let us know the value."

Me: Yes, when I reboot the microcontroller with JTAG I can read the state of the registers SR1 and CR1:

the value is 0 to both.

"3. What are the operations performed during flash initialization?"

In normal startup, (QSPI not planted); the boot ROM of the microcontroller copies 8KB from the address 0x00000 of the flash into the internal ram of the μP, but we note that when the SPI is "planted" the register TBPROT is read as = 0! Would not that be the problem?

I do not have the hand on this code (it is programmed by the maker of the microcontroller, but I guess it sets the flash in single mode.

Then the program that runs after this Boot ROM initializes the QSPI in QUAD mode to copy the application, then finishes initializing the QSPI in TBPROT mode = 1 = BP starts at low (Low address) and TBPARM = 1 = 4- kB physical sectors at top, (high address). So we have CR1 = 0x26

Then Status with:

BP [0: 2] = 111.

And finally the BankAdressRegister register with EXTADD = 1, 1 = 4-byte (32-bit) addressing required from command

I hope these clarifications will help to solve the problem of incompatibility with BOOT ROM after a power failure?

Best Regards,

Eric

0 Likes
ErFo_3086866
Level 1
Level 1

Hi,

The problem is being resolved, because it's identified.

In fact the problem comes from the register of Config and especially of its bit TBPARM.

Indeed, to unlock blocks of sectors in write access I use the command WRR to modify the Status register which contains the bits BP (Block Protection). This command is made to write on the 2 registers Status and Config, and I did not see that one could write only on the Status register.

It happened that if the power supply disappeared during the writing of the Config register, TBPARM could be accidentally modified, making incompatible the BOOT ROM of the microcontroller because the "loader program" was changed of address...

So, we think the solution is to write only on the Status register to limit the risk of blockage during an impromptu power failure.

We are validating this solution.

Best Regards,

Eric

0 Likes

Hi Eric,

We do not recommend to program status and configuration registers frequently. They can get corrupted if a power down happens during WRR operation. Please see our application note available at: http://www.cypress.com/file/207641/download for more information.


Thanks and Regards,

Sudheesh

0 Likes

Hi Sudheesh,

thank you, you confirm what we found. (We did not know the application note)...

So we changed our method, the registers SR1 and CR1 are only programmed once in the factory.

For block protection we now use DYB volatile registers.

Thanks a lot for your help !

Best Regards,

Eric F.

0 Likes