MCU-PLUS-SDK-AM243X: Watchdog does not work

Hi Felix,

I'll be coming back on this item before 31st of this month, allow me some time to analyze the thread and reply.

Thanks,

G Kowshik

Hello Kowshik,

I tried both: setting it up manually - without any SysCfg. And setting it up only with the SysCfg. Both ways do not work. So I already tested your suggestion and it does not work.

I would like to keep this open until we have found a solution for using the TI-Watchdog.

Best regards

Felix

Hi Felix,

Okay, I'll try to test this on an eval board and come back on this item before 5th September. Also, I want you to check the AM243x Example code under the location " C:\ti\mcu_plus_sdk_am243x_08_03_00_18\examples\drivers\watchdog\watchdog_interrupt "

Let us know if this works because if this too doesn't work then there's something else we need to root cause. 

Thanks

Hey Ming,

so I tried just receiving that mentioned nm-interrupt but this also does not work.

And I even saw why: The callbackFxn you can register and pass via the open-function is never called because even inside the sdk-source-code it is never applied to anything. the code does not even contain a hint where the interrupt gets triggered, neither does the TRM or I just can't find it.

The source looks like this:

So in fact, when configured to nmi, nothing happens than just a clearing of the WD-status?

So how can I even achieve a watchdog-functionality with this watchdog-implementation?

Hi Felix,

Please try to import and build the watchdog_interrupt_am243x-evm_r5fss0-0_nortos_ti-arm-clang example. Then load the OUT file onto an AM243x EVM. Set a break point in watchdogCallback(), then run the program. You should get into the break point in about 10 seconds, because the watch gog timer was set to 10000ms (10 sec). I have tried it on AM243x EVM with AM243x MCU+ SDK 08.03.00.18. It works properly.

Best regards,

Ming

Hey Ming,

I just saw in the examples that you hard-code an hw-interrupt for the Watchdog. This is not described anywhere in the documentation, neither in the API of the Watchdog. the API provides a callback-function but this seems to be in fact not used.

Will the documentation be updated on this topic? We do not use any examples and we do not use any EVM-boards. We rely on APIs and documentations.

I will try it next with the hwi and keep this thread updated.

best regards,

Felix

Hi Felix Heil

Can you show us what hard-coding are you talking about? The interrupt number is hard-coded as per the TRM's interrupt mapping for the peripheral. You can find it under the TRM's page 2161 

Thanks

Maybe "hard-coded" is a bit wrong. what I meant is that you just create that hw-interrupt, which is not mentioned in the documentation. This is "hard-coded" inside the examples but explained nowhere else.

So the example worked on our board, but as soon as I try to implement it like the example in our application it does not work. Since we have a different initialization I thought maybe the HWI is created too late and so I put it directly after the Drivers_open like you did in the example. But this did not solve the issue. The interrupt never happens. I set it to 1000 ms, 10000 ms like the example but nothing.

I did set it in SysCfg to trigger NMI interrupt WDT8 and so on:

we are creating the hw-interrupt in a C++-context:

    HwiP_Params             hwiPrms;
    int32_t                 status = SystemP_SUCCESS;
    static HwiP_Object       gRtiHwiObject;
    /* Register interrupt */
    HwiP_Params_init(&hwiPrms);
    hwiPrms.intNum      = CONFIG_WDT0_INTR;
    hwiPrms.callback    = &wdCb;
    hwiPrms.args = reinterpret_cast<void*>(this);
    status              = HwiP_construct(&gRtiHwiObject, &hwiPrms);
    
    ...
    
    void wdCb(void *callbackFxnArgs)
{
}

we never clear the watchdog. So I would expect the window is not serviced and the interrupt is issued. But it's not.

So I tried setting it up manually. There I noticed, when creating the HW-Interrupt before the clock-enables, the interrupt directly comes up as soon as we call the SOC_moduleClockEnable. Directly. So no time in between, the window is ignored.
if I change the Interrupt-construction after the clock-enable again no interrupt is issued.
This is reproducable.

What am I doing wrong?

Edit: The interrupt finally happened. but not after the setup 1000 ms but after like 100 seconds. I am investigating further. It seems the frequency/clock-configuration is somehow wrong?

Edit2: ok a second try did not resolve in the same behaviour. Again no interrupt is ever generated.

Hi Felix,

I understand the problem now, the reason you might not be getting a proper reset to the desired watchog instance may be the wrong configuration to the interrupt number. I understand that you're talking about how the interrupt numbers are being generated from the sysconfig besides not having a detailed documentation about this in TRM. Thanks for bringing this to our notice, I started reaching out internally regarding this issue to the experts and I should have something by next monday. 

Thanks for your patience. 

Hi Felix,

First of all, the WDT8 is dedicated to R5f0_0 and WDT9 is dedicated for R5F0_1 and so forth according to 12.5.2.1 RTI Overview in AM243x TRM. The CONFIG_WDT0_INTR (always to 0) will be the interrupt for all watchdog timers.

According to the  example.syscfg file in your previous post, the "WDT Expiry Time In Millisecond(ms)" was set to 10000ms which is 10 second. You should be able to get interrupt after 10 seconds. Can you reduce it to 1000ms (1 second)?

The other thing I noticed in your code is the following:

hwiPrms.args = reinterpret_cast<void*>(this);

I am not sure what it is doing. Can you comment it out for now?

Best regards,

Ming

Hey Ming, Hey Kowshik,

so as Ming said the INTR with set to 0 should be suitable. I also tried setting it to 1000 ms and a lot of other values. I also removed the hwiPrms.args assignment, but it only was the c++-object which is in charge of the interrupt-callback.
The callback itself is a static-link-time-member-function so the C-Context can access it. We also use it like this for the IPC/RPMessage where it works as expected.

I also noticed today after my vacation that I once again got the interrupt triggered. But not after the expected time-interval but completely random like 15 seconds to late. I could only reproduce once for now but the amount of time seems to differ, since this took like 11 minutes and ~10 seconds.

Is there maybe an interrupt-problem? Since the example does also not seem to use FreeRTOS-Tasks and is a no-rtos-example, but we do use Tasks. I also checked additional third-party libraries via readelf for Watchdog-symbols and after contacting them I also would exclude this as a reason, since they all do not use any Watchdog-instances.

I checked the registers of RTI8_CFG also:

The DWWD-register states the window was violated which should trigger an interrupt but no interrupt was thrown.

And now after 14 minutes and ~10 seconds another interrupt was triggered but no register except the DWDCNTR changed.

Hi Felix,

Sorry for not getting back to you in time.

Looks like there are three differences here:

1. You are using the customer board and we are using the AM243x EVM

2. You are using the FreeRTOS and we are using the NORTOS

3. You are using C++ and we are using C.

Can we eliminate the possible issues one by one?

First of all, can you repeat the watchdog_interrupt (NORTOS) on AM243x EVM?

If yes, can you repeat the same test on your customer board?

I will try to modify the same test for FreeRTOS?

Best regards,

Ming

Well currently it's hard for us here to gather an EVM but I already tested it on our board and the example works fine there.

And yes I also thought that maybe C++ can be a cause here but since it works fine in the same way for all the other SDK-drivers we use I doubt that the issue is caused by that.

best regards,

Felix

Hi Felix, 

As we discussed in the call, you will try to increase the SVC and IRQ stacks, while I am going to try the FreeRTOS version of the WatchDog example.

Best regards,

Ming

Hey Ming,

so I tried increasing the sizes:

unfortunately the problem still persists.

I also noticed that I need to power-reset our device often when debugging with the WD. Normally I use CPU Reset in CCS but it seems that this does not correctly reset the device when the WD is used. I couldn't find the root of that problem.

Best regards

Felix

Hi Felix,

Too bad the increasing of the stack size does not help. I will try the FreeRTOS version of the WatchDog example ASAP. Will let you know early next week.

Best regards,

Ming

Hi Felix,

I was able to make the watchdog example work under FreeRTOS. What I did is taking the FreeRTOS empty example from the MCU+ SDK 08.03.00.18 for AM243x and add the WatchDog test into it. It works as expected. Attached please find the zip file of the updated FreeRTOS empty example folder from the workspace.

1638.empty_am243x-evm_r5fss0-0_freertos_ti-arm-clang.zip

Best regards,

Ming

hey Ming,

yes I can confirm the example works for me. interestingly I always need to repower the device before loading the example. else the wd-cb won't be called. But anyway this does not work like that for our implementation. No matter if resetting, the callback does not get called. i will now compare step by step what could be different in our setting

ok, so the differences I saw and what I tried:

1. we use multiple different tasks straight through all priorities available. Example only has one task.
2. our startup-routine does call System_init(); Board_init(); AND Drivers_open(); Board_driversOpen(); in non-task-context. The example calls the last two inside the task in the example. I also tried to move those both in a separate function which is called in task-context, when the freeRTOS was started. Doesn't change anything. Note that the task in which context it is called is later on suspended forever, since it's only an initialization task. But that should not interfer I guess?
3. We heavily use the linker since we are placing function in the gpmc-region where we use a psram to reduce usage of internal SRAM und to increase RAM. The init-functions of the sdk are located in psram and so is the wd-callback. I directly linked the wd-callback and the creation of the hwi inside the SRAM instead of psram. Also the same for the generated files. does not help.
4. we used a c++-member function. I created a C-function like in the example as callback. Also does not help.
5. We have output via the CCS-Console, the example has not. Disabling CCS output via SysCfg does also not solve the problem.
6. we do not directly construct the hwi-object inside a tas-loop but inside a C++-Constructor. I moved it to happen directly ofter the open-functions. Also this does not help

What is the same:
1. SysCfg setting for Clock and WD are exactly the same like in the examples

Another idea I had: is the sysfw involved to that topic? since we needed to modify the sysfw a bit (only one Pin via rm is different) and compile it again. Not sure if this interferes here? The Pin is just used for an GPIO.

Note: the interrupt happens, but it always takes from 7-15 minutes instead of the proclaimed 1 second.

Hi Felix,

1. I think this should be OK

2. As long as the calling to Drivers_open() is before HwiP_construct(), then it should be OK.

3. This might be an issue, but you tried put them inside the OCRAM and still not help, so it can be ruled out

4. I think it can be ruled out too.

5. It should not be matter.

6.You also ruled it out by trying both.

I am not sure about the SysFW changes. However, I did not see any SysFW API calls inside the Watchdog_open() nor HwiP_construct().

Can you try your code with the SysFW from 08.03.00.18 without change?

Last question, does the Watchdog interrupt always happen, but takes 7 - 15 mins to come OR sometimes it happens and sometimes does not?

Best regards,

Ming

Hey Ming,

sadly I could not fix the issue.

I tried moving it out of the C-context as good as possible but it also does not fix it. I also checked if we somewhere block any interrupts but that's not the case. But we use OS-mechanisms heavily. we suspend also tasks und use mutexes, events and mailboxes. Not sure if this could somehow interfer. At least the doc of freeRTOS says the suspending of all tasks will just suspend the scheduler without locking any interrupts.

And today it seems the interrupt never happens again.

We may need a debug-session to check things here.

best regards

Felix

Hi Felix,

my colleague will schedule a debug session with you soon.

Best regards,

Ming

Hi Felix,

I need the email ID's of the stakeholders that'll be available for the call. A time slots that can work for you.

Thanks