According to RM, NCF_TO should be less than FOSU_COUNT, otherwise FCCU_FTR will occur instead of FCCU_RST when fault is injected.
69780h = 432000
Theoretically, when NCF_TO < 432000, only FCCU_RST will occur. But in fact, I configured it to 400000 and FCCU_FTR occurred. When I gradually reduced it, I found that NCF_TO can only be configured to a maximum of 200000 to ensure that FCCU_RST instead of FCCU_FTR occurs. I think the difference between 200000 and 432000 is a bit big. I need to know the reason. Attached is the configuration screenshot when I did the test
Hello,
I do not know which chip you are using.
However, FOSU will take action if FCCU does not in ALARM state.
Therefore FOSU reset is destructive, as the recovery was not possible or wasn't happen within ALARM timeout.
For example S32K3:
I found that NCF_TO can only be configured to a maximum of 200000 to ensure that FCCU_RST instead of FCCU_FTR occurs.
Can't comment on that. Please stick with reference manual max FOSU count for your TO settings.
Best regards,
Peter
I don’t want to repeat the explanation, I will describe my testing process in a more direct way.
Use this configuration
The result after injecting fault is
Use this configuration
The result after injecting fault is
The way to inject faults is to write 0xF to the FCCU_NCFF register.
You can see that the difference between the two configurations is NCF_TO, which is less than 0x69780 in RM. Can you try it based on this? Because I think the result of this control experiment is very obvious, I really don’t know where the problem lies
Hello,
I have just tested it and it works as expected.
after injecting NCF3
Attached is my printed configuration before fault injection.
Best regards,
Peter
The chip I use is S32K312. According to RM, the value of NCF_TO is OK if it is less than 432000. So I set it to 400000 and it should work, but the actual test result is different from RM. I can only set a relatively small number (200000) to work. So I am confused about this. If you have done relevant tests and proved that setting it to 400000 is feasible, please post the settings of FCCU registers and I will do another test based on it. The following is a test scenario I assumed. My test result is that when Recovery Timeout = 400000, FOSU reset is responded instead of FCCU reset.
Hello,
I will not comment on your SW driver or some GUI settings.
I can express how the FCCU work on register level.
To calculate correct TO value you will use following formula:
This will give you number of clocks for ALARM state of FCCU when fault comes.
Tclk_safe is your FIRC:
and also:
you have to respect the FOSU timeout - which is supervisor unit of FCCU:
So all what the ALARM state require is to set the Tmax_alarm to value less then 0x69780 (which is time when FOSU will take action).
This is valid independent of any drivers/tools you will be using. Just make sure your registers carry correct values.
Best regards,
Peter
Correction: Only short reset is selected as the fault response, because other responses will cause the FOSU counter to stop.
