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

Nor Flash Forum Discussions

jili_1690266
Level 1
Level 1
First reply posted First question asked Welcome!

親愛的

我們項目使用flash(S70FL01GSAGMFI010)時,小概率出現flash部分內容丟失的情況。有時候啟動代碼丟失,導致板子完全起不來。

針對閃存內容異常丟失的問題,由於暫時沒有找到根本原因,因此,準備將閃存低1M(放置啟動代碼區域)保護起來。

 

實現保護的流程如下:

在板子激活/初始化flash時,

(1)查看TBPROT(CR1 bit5)是否等於1,若為否,則設置為1;反之不操作。

(2)查看BP2 / BP1 / BP0(SR1 bit2〜bit4)是否等於001,若為否,則設置為001;反之不操作。

(3)查看QUAD(CR1 bit1)是否等於1,若為否,則設置為1;反之不操作。

但是,第一次,TBPROT設置為1後,BP2 / BP1 / BP0設置不成功。SR寫入0x4,返回值卻是0x9c,似乎進入了flash異常保護狀態。都是0x9c。

 

查閱數據表,發現TBPROT要求必須在第一次編程的時候設置。但是在新的flash上​​做以上操作,仍然進入了異常保護狀態,flash重新後SR為0x9c。

 

綜上,有以下三個問題請幫忙解答一下:

  1. 不考慮軟件代碼的情況下,flash部分內容丟失的問題,通常會是什麼原因導致的?
  2. 設置TBPROT,為什麼會導致flash進入異常保護狀態?是否是遺漏其他重要步驟?
  3. 對於已經進入異常保護的flash,有沒有辦法恢復到正常狀態?

 

jili_1690266_0-1619429563324.jpegjili_1690266_1-1619429577757.jpegjili_1690266_2-1619429587011.jpeg

0 Likes
1 Solution
AS_36
Moderator
Moderator
Moderator
500 replies posted 250 solutions authored 250 replies posted

Hi @jili_1690266 

Please find the answers to your initial three questions below - 

1. Regardless of the software code, flash part of the content loss of the problem, usually what causes? An unintended erase or an incomplete programming can cause this situation to occur. The flash cannot change programmed bits back to 1 on its own.

2. Setting TBPROT causes flash to go into an abnormal protection state? Are other important steps missing? It’s  not recommended to change the TBPROT bit after changing the array content since doing so may result in misconfiguration of the protection schemes of your sectors. There could be something else related to this bit being OTP that may lead to more serious damage/misconfiguration of the device.

3. Is there a way to get back to normal for flash that has entered exception protection? All the programmed bits of SR/CR (SRWD, BP2-0, TBPROT, BPNV, QUAD) are non volatile or OTP bits, therefore the SR/CR value remain constant even after reset. SR = 0x9C indicates that the SRWD bit is set. If the SRWD bit is set and WP# signal is LOW, programming the SR/CR is not allowed. You can try to drive WP# HIGH and try programming SR/CR.

Let me know if you have more questions.

Regards.

 

View solution in original post

0 Likes
4 Replies
AS_36
Moderator
Moderator
Moderator
500 replies posted 250 solutions authored 250 replies posted

Hi,

I would like to ask you a few questions to get a better understanding of the issue before I can answer your questions. Please see below - 

  • Can you please clarify what do you mean by "some of the flash content will be lost"? What is the expected data and what is data that you are observing in the flash?
  • Did you read back the contents of the flash after you had programmed it initially? Was the programming successful with the correct data programmed to the flash?
  • The mentioned device (S70FL01GS) has two chip select lines (CS#1 and CS#2). Can you confirm that both CS# lines are being handled correctly for each operation?
  • Can you tell the exact step by step sequence of commands and CS# toggling you have performed for the program operation on status and configuration registers?
  • Is the flash device old or new? Is there a chance that excessive program operations would have been performed on SR/CR registers exhausting all their P/E cycles?
  • Is there any possibility of abrupt power failures during the WRR operation?
  • You have also underlined the CR1 bit3 in the second image. Have you also programmed that bit?
  • Can you tell me the default values of SR and CR register after power on?

Regards.

0 Likes

Hi,

I would like to ask you a few questions to get a better understanding of the issue before I can answer your questions. Please see below - 

  • Can you please clarify what do you mean by "some of the flash content will be lost"? What is the expected data and what is data that you are observing in the flash?

[YE] We saved fsbl, uboot, kernel and application excutable files in flash. When xilinx board startup, OCM will search fsbl from flash. Then, fsbl will look up uboot in flash, and copy it from flash to DDR. Later, Uboot  will look up kernel in flash, and copy it from flash to DDR.

 "some of the flash content will be lost" means the fsbl, uboot, or kernel file lost in flash. For example, uboot saved @0x4000000~0x4080000, but in abormal case, the datas are all 0xFF at addr 0x4000000~0x4080000.

 

  • Did you read back the contents of the flash after you had programmed it initially? Was the programming successful with the correct data programmed to the flash?

[YE] Yes, we will read back the contents after programmed. Program is successful.

 

  • The mentioned device (S70FL01GS) has two chip select lines (CS#1 and CS#2). Can you confirm that both CS# lines are being handled correctly for each operation?

[YE] Yes, both CS# lines are being handled correctly.

 

  • Can you tell the exact step by step sequence of commands and CS# toggling you have performed for the program operation on status and configuration registers?

[YE] Test steps on the new flash as following:

Step1.  Read default SR and CR value. (SR=0 CR=0)

Step2.  Check TBPROT bit set or not, if not, set it as 1; otherwise no operation here.  (SR=0 CR=0x20)

Step3.  Check BP2~1 bit set as 001 or not, if not, set it as 001; otherwise no operation here. 

Step4.  Read back SR and CR value. The expected values : (SR=0x4 CR=0x20), but the actul is : (SR=0x9c CR=0x20/0x28)

Step5.  Check QUAD bit set or not, if not, set it as 1; otherwise no operation here.  (SR=0x9c CR=0x22/0x2a)

 

After reset,

Step1.  Read default SR and CR value. (SR=0x9c CR=0x22/0x2a)

SR register is abnormal now, following steps ignored.

 

  • Is the flash device old or new? Is there a chance that excessive program operations would have been performed on SR/CR registers exhausting all their P/E cycles?

[YE] We do the same test on both two old and new flash. They are all go to the abnornal protected cases.

As last reply, the operations are as below,  There are no excessive program operations.

 

  • Is there any possibility of abrupt power failures during the WRR operation?

[YE] Power is OK when WRR operation.

 

  • You have also underlined the CR1 bit3 in the second image. Have you also programmed that bit?

[YE] No, I never set the CR1 bit3, but sometimes when SR is 0x9c, the CR1 bit3 is 1.

 

  • Can you tell me the default values of SR and CR register after power on?

[YE] In the old flash, after power on, the default values of SR = 0x0 and CR = 0x2( we used quad mode, bit2 is already set at the first time ). 

In the new flash, the default values of SR = 0x0 and CR = 0x0. 

0 Likes
AS_36
Moderator
Moderator
Moderator
500 replies posted 250 solutions authored 250 replies posted

Hi,

  • Is it possible for you to reproduce the issue with SR and CR and provide the SPI waveforms for all the transactions?
  • Is it possible for you to provide the data dump for both expected data and corrupted data (data after content loss) ?

Regards.

0 Likes
AS_36
Moderator
Moderator
Moderator
500 replies posted 250 solutions authored 250 replies posted

Hi @jili_1690266 

Please find the answers to your initial three questions below - 

1. Regardless of the software code, flash part of the content loss of the problem, usually what causes? An unintended erase or an incomplete programming can cause this situation to occur. The flash cannot change programmed bits back to 1 on its own.

2. Setting TBPROT causes flash to go into an abnormal protection state? Are other important steps missing? It’s  not recommended to change the TBPROT bit after changing the array content since doing so may result in misconfiguration of the protection schemes of your sectors. There could be something else related to this bit being OTP that may lead to more serious damage/misconfiguration of the device.

3. Is there a way to get back to normal for flash that has entered exception protection? All the programmed bits of SR/CR (SRWD, BP2-0, TBPROT, BPNV, QUAD) are non volatile or OTP bits, therefore the SR/CR value remain constant even after reset. SR = 0x9C indicates that the SRWD bit is set. If the SRWD bit is set and WP# signal is LOW, programming the SR/CR is not allowed. You can try to drive WP# HIGH and try programming SR/CR.

Let me know if you have more questions.

Regards.

 

0 Likes