The alarm state timeout interval (NCF_TO[TO]) cannot be set larger

[Janeting123]

Janeting123_0-1729079791538.png

According to RM, NCF_TO should be less than FOSU_COUNT, otherwise FCCU_FTR will occur instead of FCCU_RST when fault is injected.

Janeting123_1-1729080043923.png

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

Janeting123_2-1729080528142.png

[petervlna]

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:

petervlna_0-1729148657976.png

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.

petervlna_1-1729148894621.png

Best regards,

Peter

[Janeting123]

I don’t want to repeat the explanation, I will describe my testing process in a more direct way.
Use this configuration

Janeting123_2-1729739526993.png

The result after injecting fault is

Janeting123_3-1729739539071.png

Use this configuration

Janeting123_4-1729739561121.png

The result after injecting fault is

Janeting123_5-1729739568613.png

The way to inject faults is to write 0xF to the FCCU_NCFF register.

Janeting123_6-1729739621056.png

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

[petervlna]

Hello,

Thank you for sharing details.

I will test your setup here and let you know my observations ASAP.

Best regards,

Peter

[petervlna]

Hello,

I have just tested it and it works as expected.

petervlna_0-1730960753873.png

after injecting NCF3

petervlna_1-1730960770471.png

Attached is my printed configuration before fault injection.

Best regards,

Peter

[Janeting123]

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.

Janeting123_0-1729150205867.png

[petervlna]

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:

petervlna_0-1729227475403.png

This will give you number of clocks for ALARM state of FCCU when fault comes.

Tclk_safe is your FIRC:

petervlna_3-1729227883398.png

and also:

petervlna_1-1729227551015.png

you have to respect the FOSU timeout - which is supervisor unit of FCCU:

petervlna_2-1729227610683.png

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

[Janeting123]

I noticed the points you mentioned in RM. I also clearly stated in my previous statement that the problem I encountered was that the actual test results were different from the expectations, not that I did not read RM. This does not solve my problem. If you have done relevant tests, please post your process.

[petervlna]

Hello,

Not sure how to help here. I did not play with driver you are using.

My test result is that when Recovery Timeout = 400000, FOSU reset is responded instead of FCCU reset.

I am not familiar with what the values Timeout=400000 represents when written in the TO register.

The point is however still the same.

After you do initialization, check the value in TO register in debug mode. You will see true hex value in the TO register which your compiler translated.

It must be in range Tmax. Refer to the equation TOxTclk_safe.

If your TO register contains value greater then FOSU timeout, your see correct behavior.

Best regards,

Peter

[Janeting123]

Janeting123_0-1729082375420.png

Correction: Only short reset is selected as the fault response, because other responses will cause the FOSU counter to stop.