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 <h...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
