[U-Boot] [PATCH] dfu: cmd: trigger watchdog before calling usb_gadget_handle_interrupts

[Lukasz Majewski]

Hi Heiko,

> Hello Lukasz,
> 
> Am 17.03.2015 16:16, schrieb Lukasz Majewski:
> > Hi Heiko,
> >
> >> Hello Lukasz,
> >>
> >> Am 17.03.2015 13:56, schrieb Lukasz Majewski:
> >>> Hi Heiko,
> >>>
> >>>> Hello Lukasz,
> >>>>
> >>>> Am 17.03.2015 10:52, schrieb Lukasz Majewski:
> >>>>> Hi Heiko,
> >>>>>
> >>>>>> trigger watchdog before calling usb_gadget_handle_interrupts()
> >>>>>> This prevents board resets when calling dfu command on boards
> >>>>>> which have a watchdog.
> >>>>>>
> >>>>>> Signed-off-by: Heiko Schocher <hs at denx.de>
> >>>>>> ---
> >>>>>>
> >>>>>>     common/cmd_dfu.c | 2 ++
> >>>>>>     1 file changed, 2 insertions(+)
> >>>>>>
> >>>>>> diff --git a/common/cmd_dfu.c b/common/cmd_dfu.c
> >>>>>> index e975abe..46af4cf 100644
> >>>>>> --- a/common/cmd_dfu.c
> >>>>>> +++ b/common/cmd_dfu.c
> >>>>>> @@ -9,6 +9,7 @@
> >>>>>>      */
> >>>>>>
> >>>>>>     #include <common.h>
> >>>>>> +#include <watchdog.h>
> >>>>>>     #include <dfu.h>
> >>>>>>     #include <g_dnl.h>
> >>>>>>     #include <usb.h>
> >>>>>> @@ -64,6 +65,7 @@ static int do_dfu(cmd_tbl_t *cmdtp, int flag,
> >>>>>> int argc, char * const argv[]) if (ctrlc())
> >>>>>>     			goto exit;
> >>>>>>
> >>>>>> +		WATCHDOG_RESET();
> >>>>>>     		usb_gadget_handle_interrupts();
> >>>>>>     	}
> >>>>>>     exit:
> >>>>>
> >>>>> It seems strange for me, that we must reset watchdog when
> >>>>> looping in the dfu.
> >>>>
> >>>> Hmm.. maybe I overlook something, but If you look into this
> >>>> while(1) loop, there is no trigger of the watchdog ... and if I
> >>>> start the dfu command without a USB cable on the board, what
> >>>> triggers the boards watchdog?
> >>>
> >>> So the problem is when cable is not attached to the board and you
> >>> call dfu command to execute?
> >>
> >> Yes.
> >
> > For UMS gadget there is defined g_dnl_board_usb_cable_connected()
> > function.
> >
> > However, it is not yet supported in dfu and requires working MUIC
> > block, which might be not available at your board.
> 
> Maybe, I must check this ...
> 
> >>>>> What is the WATCHDOG interval on the affected board?
> >>>>
> >>>> ~5 seconds
> >>>>
> >>>> Ah, this is on an at91 board .. and in the
> >>>> drivers/serial/atmel_usart.c atmel_serial_tstc() is no
> >>>> WATCHDOG_RESET...
> >>>>
> >>>> So ctrlc() does not trigger the watchdog
> >>>
> >>> Could you be a bit more specific here. Does your board expect
> >>> ctrlc() to update watchdog, so it won't reset?
> >>
> >> I do not know, if ctrlc() must trigger the WDT ... I just looked
> >> into the while(1) loop in common/cmd_dfu.c. There is only ctrlc()
> >> which could trigger the WDT... and on at91 it does not trigger
> >> it ...
> >
> > By trigger you mean reset WDT core and don't reset the board?
> 
> I mean, the code must trigger the WDT somewhere in this while(1).
> If not, the WDT resets the board.
> 
> >> If dfu transfer is started there is some output on the console,
> >> which triggers the WDT too ... do you have a board with a running
> >> WDT?
> >
> > On trats/trats2 we disable WDT when we enter the u-boot.
> 
> Why?
> 
> So you can test this behaviour. Do not disable the WDT and start
> the dfu command ... the board should reset when you start the dfu
> command (without starting dfu-util on the host, and if ctrl() does not
> call WATCHDOG_RESET for your hw) ... with my patch it should work ...
> 
> BTW: I could not disable the WDT on this board, once it is enabled.
> So disabling the WDT is no option ... :-(

Ok, I see. Then I will apply the proposed patch.

> 
> > I can imagine following situation when WDT is enabled when u-boot
> > starts (its timeout is ~5sec) and then you start dfu transfer with
> > not connected cable.
> > Then 5sec pass since cable is not connected and no transfer is
> > ongoing. This causes board reset by WDT.
> >
> > Am I right?
> 
> Yes, because the WDT gets not triggered in this while(1). And maybe
> if you start the dfu command with connected cable, but not starting
> dfu-util on the host also, but I have not yet running the usb gadget
> on this at91 board (at91sam9g20 based) ...

Thanks for explanation. I just wanted to have bigger picture of the
problem.

> 
> bye,
> Heiko


-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group