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 ... :-(
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) ...
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
