Hi,
when I used Pmic_InitDevice to config Pmic, the return value of this function is E_NOT_OK. I traced the code and found that it could not clear errorCounter in Pmic_VR55XX_ClearFault on RDB3.
Hi,
Which RTD version are you working with? Also, is this behavior with the provided NXP example?
Please, let us know.
when I invoked the interface of Pmic_ClearFault, the pmic state is FS_STATES_FSM_STATES_ASSERT_FS0B, and window duration is 0xE200, the condition is not satisfied:
The RTD version is S32G2 RTD AUTOSAR 4.4 D2210.
I used the NXP example, the result is same too.
When I tested the NXP example, I used SW10 to config both OFF, and J184 is shorted (debug mode).
Hi,
Thanks for your feedback. We have used the same versions that you are saying and under an RDB3 platform we see the following outcome with the "Wdg_VR5510_HLD_Example_S32G399A_M7" example:
In which the function "Pmic_InitDevice" is returning an E_OK.
Have you applied any additional modifications to the example? This should be the expected outcome out-of-the-box.
Please, let us know.
Thanks for your reply.
I initialized VR5510 and related modules in bootloader and fed watchdog in application. When bootloader jumped to application, I found the board reset.
If I want to feed watchdog normally in application, do I need to initialize VR5510 and related modules again in application?
Hi,
Thanks for your feedback. If it was already initialized, have you tried only feeding the WDOG?
From our side, we have the following information:
"
...the Wdg_43_VR5510_SetTriggerCondition is the necessary step of feed WD and it follow the Specification of Watchdog Driver for the AUTOSAR.
In fact, the real dog feeding depends on this GPT (dog feeding clock), which means that the application layer calls the dog feeding function (Wdg_SetTriggerCondition) not to directly operate the watchdog hardware register, but to configure the GPT, and then use the GPT Interrupt callback to operate watchdog hardware registers.
"
Please, let us know.