RSL10 Watchdog interrupt routine

Hi there.
I have a following piece of code, which unfortunately never goes into interrupt handler routine.

trace_* functions were taken from the example source code.
What I would like to achieve is to use watchdog irqhandler together with _Unwind_Backtrace and trace_printf to display an information what was executing that caused a watchdog reset.

I can’t use plain old debug breakpoints the device is going into a deepsleep which disconnects the debugger. Any idea why the code isn’t going into a IRQ handler?


The behavior was verified with debugger as well, the breakpoint never reached the handler.

Hello @l.miklosko,

I have run a quick test on my end to try and verify the issue you are seeing, but can not reproduce the behavior. I have attached the firmware I used to test below so you can validate this as well. The UART terminal should be set to 115200 while running this firmware, at which time you should see “Watchdog Interrupt” printed every ~4.1 seconds.

As an initial guess about what went wrong in the firmware you describe above, it looks like it might be an issue with the configuration on the Trace Print implementation, or may also possibly be caused by calling the “trace_init()” functions before each print (this initialization only needs to be called on device restart or sleep wakeup).

If you have any further questions about this setup, please let us know.

blinky_Watchdog.zip (64.7 KB)

Thank you for using our Community Forums!

Hi @brandon.shannon,

thank you for your time to look into it. Calling trace_init() should not be a problem as it calls HAL_UART_Init() which checks if the device was initialized and does nothing in this case. I verified that by removing the trace_init from the routine. Furthermore I validated this by setting a hardware breakpoint inside the routine which was not reached as well inside the debugger. As I read on the forum, the Watchdog reset is disabled while in the debugger, but should trigger the interrupt anyway.

I am yet to try your example and see if that works.

Thanks & Best,
Lukas

Hi @l.miklosko,

If you are launching the firmware via the Eclipse debugger I do not believe that Watchdog Interrupt will be triggered as the timeout is considered ‘disabled’.

It might be worth trying your firmware setup again without the debugger attached to see if you experience a different behavior.

Hi @brandon.shannon,

I’ve tried to detach the debugger, but still observing the same behavior.
As far as your application goes, it took me some time to figure out the pin for UART to run it (for anybody trying to use that application, it’s pin 5) - although still without success. Additionally, based on the macros in printf.h file, I had to define the OUTPUT_INTERFACE to OUTPUT_UART for PRINTF macros to do anything useful - otherwise they were defined as empty macros.

That being said, still no luck getting watchdog interrupt to fire.

Best,
Lukas

Hi @l.miklosko,

I have attached a compiled .hex file to this response. Please give this firmware a try and let me know the outcome. The TX pin is DIO5, the RX pin is DIO4, and the baud rate is 115200. This will help us determine if this is a hardware or firmware setup issue, as I can confirm 100% that I am able to see the Watchdog UART print every ~4.1 seconds on my end.

blinky_Watchdog.hex (13.8 KB)

Hi @brandon.shannon,

Unfortunately, even when programmed your hex file onto the device, I still cannot see anything in the console. I am using standard RSL10 SiP Development board (the one with lots of jumpers on it).


Update: I was connecting the wrong pin. I am starting to be blind TBH. I was using pin 15 instead of 5. I can see the output Watchdog Interrupt every ~4s. I am gonna try and build the project you gave me again.

Update2: @brandon.shannon After compiling your project, I can clearly see the output once again in the terminal.
Any idea why my program behaves differently?

Alright @brandon.shannon,

I figured it out. The application I am working on was forked from the sense_ics_firmware_sleep. In the example, they’ve been using TRACE_PRINTF macro, which is a replacement for printf() function defined in stdio.h. They have a syscalls_hal_uart.c file, which defines the following function:

int _write(int file, char* ptr, int len)
{
    int retval = -1;

    if (file == STDOUT_FILENO || file == STDERR_FILENO)
    {
        // Send output only when not in interrupt
        if (HAL_IsInterrupt() == false)
        {
            if (HAL_UART_Send(ptr, len) == HAL_OK)
            {
                retval = len;
            }
            else
            {
                retval = -1;
            }
        }
    }
    else
    {
        retval = _app_write_hook(file, ptr, len);
    }

    return retval;
}

As you can see, there is a check whether the code is called from the interrupt handler, thus the actual uart write was never executed - acting like the watchdog irq was never fired.

Thank you for your cooperation on this one.


Bonus question: As I’ve said before, I am trying to put the _Unwind_Backtrace call inside the Watchdog ISR to determine the root cause of the watchdog firing. The only problem is, it is missing these references: __exidx_start and __exidx_end. Do you know where should I put these inside the following linker script? (not modified from the same example as described in my previous answer):
sections.ld (7.0 KB)

2 Likes

Hi @l.miklosko,

Good to hear the UART Print implementation is working on your end now!

As for placing these symbols in the linker script, if you are using Sleep mode I recommend placing them within FLASH so they are retained between sleep cycles (DRAM/PRAM is powered down unless explicitly changed), but if Sleep mode is not used there should be no issue placing them in either the FLASH or DRAM/PRAM sections.