I have implemented the external watchdog (Wdg_43_VR5510) for PMIC. But it is going into endless loop in Pmic_VR5XX_TimeoutLoops_StateTransistion (refer below).
Currently it is in INIT_FS state, as per the state diagram it says we need to have a good watchdog refresh to change the state from INIT_FS to Wait_ABIST2.
To Satisfy the first good watchdog refresh within 256ms, we have called watchdog trigger API after Wdg_43_VR5510_Init function during EcuM Initialization.
We need to know, how and where to call the first watchdog refresh. So that the state transition happens from INIT_FS to wait_ABIST2.
Hello @Jerry_cao ,
Thank you for contacting us. However, the original post has been closed for nearly two years, so we are unable to continue supporting you under that thread.
Please create a new post for your issue on S32G - NXP Community, and our team will be happy to assist you further.
BR
Celeste
Hello NXP team,
I'm currently debugging the VR5510 PMIC and have run into a real-time scheduling issue related to the watchdog refresh.
The MCAL I2C watchdog refresh (feeding the VR5510 watchdog over I2C) is implemented as a synchronous operation. Because we call it from within an interrupt context, the synchronous wait blocks the CPU and degrades the real-time scheduling of other tasks.
I noticed there is an asynchronous option in the driver configuration/code. However, in practice it still performs a synchronous busy-wait (it blocks and polls until the I2C transfer completes), so it does not actually decouple the transfer from the caller.
My questions:
- Is there an officially supported way to make the VR5510 watchdog refresh truly non-blocking (e.g. interrupt-driven or DMA-driven I2C), so that it does not stall other tasks?
- If the asynchronous option is expected to be non-blocking, is the current synchronous busy-wait behavior a known limitation or a configuration issue on my side?
Any guidance, reference configuration, or example code would be greatly appreciated.
Thank you.
Hello SagarZala,
I wonder if you have tried the two out-of-the-box examples in S32 Design Studio (S32DS)? Will they have the same problem? May be they are very good references for you.
Hi,
Thanks for the reply.
I am using RTD version 4.0.2. I have already configured the I2C at high speed and WD_WINDOW is also configured at 1024ms. But still its not working.
Dear @SagarZala ,
Thank you for your question. VR5510 is commonly paired with the S32G microprocessor. For this, the available drivers for VR5510 should be provided under the S32G RTD packages. Which RTD version are you using and which specific example is it?
Taking the RTD 4.0.0 version as an example, you can find the documents "RTD_WDG_43_VR5510_IM" and "RTD_WDG_43_VR5510_UM" under the path C:\NXP\SW32G_RTD_4.4_4.0.0\eclipse\plugins\Wdg_43_VR5510_TS_T40D11M40I0R0\doc. The document "RTD_WDG_43_VR5510_UM" describes more detail.
It is worth mentioning that the watchdog is triggered via the I2c command and it depends on the I2c speed. When the I2c speed is low, the watchdog may not be triggered successfully within the watchdog's window open time. To avoid this problem, we recommend that the user configure I2c with high speed and use a large window period when it is enabled.
To set the watchdog refresh, you can configure the WD_WINDOW [3:0] to obtain the refresh time. As shown in the following figure:
Refer to "Document VR5510 Product data sheet", page 60, Table 45. Watchdog window period configuration, as shown in the screenshot below. And after setting the correct WD period time, you need to correctly feed the WD.
Hope the above information is helpful to you.
Best Regards,
Celeste