S32K142 Flash

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

S32K142 Flash

1,413件の閲覧回数
A_Jabb
Contributor I

Hi,

I am trying to write a robust code for S32K142 flash driver. I tried to make erroneous situations to examine the system response and encountered some problems:

  1. I use Program Phrase Command to program the D-Flash and run the code from P-Flash with no problems. But when an unaligned address or incorrect command code is used (expect to set FSTAT[ACCERR]), a CPU core lock-up happens (like a command is using P-Flash and you try to execute your code from P-Flash). I tried to execute the command and wait for CCIF flag in RAM and it was OK and ACCERR was set. Why a wrong command has conflict with running code from P-Flash?
  2. The reference manual states that when FSTAT[ACCERR] is set, no flash command or EEE write is allowed to start. When the flag was set, I tried to write in EEE and it didn't write but when I executed a new flash command, it didn’t run but cleared ACCERR flag itself. The subsequent commands ran with no problem. Isn’t this a contradiction?
  3. I tried to program an address in D-Flash with Program Phrase command several times (without an erase in between). Depending on the data, after a few writes, an uncorrectable ECC error happens and reading that address results in a hard fault interrupt. Since MCU does not prevent re-programming an address, should I always verify it is erased before I use program phrase command?

Thanks for your attention. I’m looking forward to your reply.

0 件の賞賛
5 返答(返信)

1,375件の閲覧回数
danielmartynek
NXP TechSupport
NXP TechSupport

Hello @A_Jabb,

 

1.

Can you show the content of the FCCOB registers of the command that causes the issue?

 

2.

How do you write the FSTAT register to clear CCIF.

Read-modify-write operation on FSTAT with ACCERR set will clear that bit.

 

3.

Please follow the S32K1xx Safety Manual, Section 5.4.1.2 Runtime checks (rev.7.1)

 

Regards,

Daniel

0 件の賞賛

1,371件の閲覧回数
A_Jabb
Contributor I

1. Any unused command code with FCCOB0[bit6] == 1 (E.g. FCCOB0 = 0xFF) causes the issue (execute FCCOB0 = 0xBF does not cause core lock-up and only sets the ACCERR).

or valid commands like Program Phrase that try to write in an unaligned address of P-Flash (Program Phrase that try to write in an unaligned address of D-Flash does not cause core lock-up and only sets the ACCERR).

2. FTFx_FSTAT |= FTFx_FSTAT_CCIF_MASK;

note: (FTFx_FSTAT_CCIF_MASK = 0x80)

2022-06-21_17-44-49.jpg

It works like you said but the RM (Rev. 14) section 36.4.4.1.2.4 statement is different.

Also RM section 36.5.9.1.2 is like what you said.

 

thanks

0 件の賞賛

1,342件の閲覧回数
danielmartynek
NXP TechSupport
NXP TechSupport

Hi @A_Jabb,

I have just tested launching FTFC->FCCOB[3] = 0xFF and ACCERR is set by this command. Also, Program Phrase (FTFC->FCCOB[3] = 0x07) with an unligned address (0x30004) does set the ACCERR flag.

Can you please share the content of all the FCCOB registers?

Anyway, exceptions are escallated to core lockup if there is no exception handler.

Do you have void HardFault_Handler(void){} in the project?

 

BR, Daniel

 

 

 

 

 

 

0 件の賞賛

1,307件の閲覧回数
A_Jabb
Contributor I

Hi,

I checked with different FCCOB content and it didn't matter. you can try with all other FCCOBs to be 0.

I have a simple Hardfault handler that works fine with other faults.

The thing is that with everything the same but FTFC->FCCOB[3] = 0xFF or 0xBF the system reacts differently.

Anyway, I have to move on from the subject. Thanks for your help ♥.

0 件の賞賛

1,279件の閲覧回数
danielmartynek
NXP TechSupport
NXP TechSupport

Hello @A_Jabb,

I really can't reproduce it.

With command 0xFF and with all the rest of FCCOBx = 0x00, I just see ACCERR = 1.

Can you share the project?

 

BR, Daniel

0 件の賞賛