Does anyone have any information or experience of the above ?

I'm using Keil RealView on a custom LPC214x board.

I've noticed that, following a watchdog reset, the USB doesn't always appear to come up properly, whereas following an external reset it consistently does.

Using the (somewhat modified) sample USB HID project, about 50% of the time the USB interface comes up and Windows starts polling the device (GetHIDReports). The other 50%, the USB interface appears to come up (in that I can see the USB descriptors), but there is apparently no polling from the host. This only happens following a watchdog reset. Following an external reset, it works as expected every time.

Using a software-based USB Analyser (BusHound), it would appear that sometimes there is no reset on the USB bus following the watchdog reset. Sometimes there is, but it is delayed by a second or two from the watchdog reset. I haven't observed any consistent correlation between this and the subsequent polling (or lack of) from the host.

Any ideas/suggestions ?

David. Start a New Thread

Hi Herbert,

Thanks for the prompt response. Much appreciated. However, I'm not
sure I completely follow what you're saying.

The normal purpose of the watchdog is to reset the CPU in the event
the firmware has locked-up, gone off into "hyperspace", etc, so I
can't insert code to do as you suggest BEFORE the reboot. I know that
the watchdog can be configured to generate an interrupt rather than a
reset, so I suppose it could be done in an interrupt handler, but, if
the system has become unstable, I can't rely on the interrupt handler
(or much else).

On the subject of the disconnect time, I may not have a sufficient
delay before re-enabling the USB interface. I'll look at doing what
you suggest at startup, following a watchdog-generated reset.

If the "disconnect time is simply too short to be recognized by the
host", why would the host stop polling ? Presumably, there is some
form of timeout after which the host gives up ? I'll need to dig out
that USB spec again !!!

I'm still concerned though that the difference exists between the two
types of reset. As I said in the oirginal post, an external hardware
reset appears to work every time. I'll have a look at how long the
two types of reset last.

Regards,

David.

--- In l..., Herbert Demmel wrote:
>
> David,
>
> as far as I've seen, you can solve that problem by disabling the
USB port
> (via diabling the pullup resistor driven byP0.31/CONNECT) before
your let
> the wathdog restart, wait a while and do the reboot then.
>
> I assume the disconnect time is simply too short to be recognized
by the
> host. A different approach would be to wait some time on power up
until you
> enable the pullup resistor to have the required disconnect time
(about 100
> or 200 ms as far as I know).
>
> Herbert
>
> At 15:15 09.01.2007 +0000, you wrote:
>
> >Does anyone have any information or experience of the above ?
> >
> >I'm using Keil RealView on a custom LPC214x board.
> >
> >I've noticed that, following a watchdog reset, the USB doesn't
always
> >appear to come up properly, whereas following an external reset it
> >consistently does.
> >
> >Using the (somewhat modified) sample USB HID project, about 50% of
the
> >time the USB interface comes up and Windows starts polling the
device
> >(GetHIDReports). The other 50%, the USB interface appears to come
up (in
> >that I can see the USB descriptors), but there is apparently no
polling
> >from the host. This only happens following a watchdog reset.
Following an
> >external reset, it works as expected every time.
> >
> >Using a software-based USB Analyser (BusHound), it would appear
that
> >sometimes there is no reset on the USB bus following the watchdog
reset.
> >Sometimes there is, but it is delayed by a second or two from the
watchdog
> >reset. I haven't observed any consistent correlation between this
and the
> >subsequent polling (or lack of) from the host.
> >
> >Any ideas/suggestions ?
> >
> >David.
> Start a New Thread

Hi Herbert,

I don't know what LPC device you're using but I believe the LPC214x
devices are only ESD-rated to 4kV. I would guess that the watchdog is
being "reset" (along with probably everything else) but the internal
state will not be predictable. How do you know the watchdog is
"active" after zapping ?

Have you considered using a dedicated external watchdog device that
can be suitably ESD-protected ? It could be "fed" via one or more
GPIO lines from the LPC device and perform a proper external reset
when it times out. I haven't done H/W design in a very long time so
can't suggest any specific parts.

Inserting a suitable delay (250mS) in my startup code BEFORE enabling
the USB seems to work. It will need further testing but it is looking
good. It could be made conditional on watchdog-generated resets but,
for now at least, I can live with the overhead on normal resets too.
Thank-you for your suggestions.

There doesn't seem to be a need to explicitly disable the pullup
resistor as I believe this is done by the reset mechanism.

Regards,

David.

--- In l..., Herbert Demmel wrote:
>
> Hi David,
>
> see my comments below.
>
> At 15:11 10.01.2007 +0000, you wrote:
>
> >Hi Herbert,
> >
> >Thanks for the prompt response. Much appreciated. However, I'm not
> >sure I completely follow what you're saying.
> >
> >The normal purpose of the watchdog is to reset the CPU in the event
> >the firmware has locked-up, gone off into "hyperspace", etc,
>
> I currently do have the problem that when "shoot" with 10kV (the
project
> I'm working on has to recover even from 15 kV automatically) to the
board,
> the watchdog does not hit and the software goes into the nirvana :-(
> Any ideas about this issue? The watchdog *is* active, I've tested
it, and
> it is serviced in the main loop of the firmware only once, so I
can't see
> any reson why it does not trigger in that case.
>
> >so I
> >can't insert code to do as you suggest BEFORE the reboot. I know
that
> >the watchdog can be configured to generate an interrupt rather
than a
> >reset, so I suppose it could be done in an interrupt handler, but,
if
> >the system has become unstable, I can't rely on the interrupt
handler
> >(or much else).
>
> I agree. I noted this because I mentioned that problem when doing a
> "forced" reset via the watchdog not servicing to make a controlled
reboot
> with a fresh enumeration of the USB bus.
>
> >On the subject of the disconnect time, I may not have a sufficient
> >delay before re-enabling the USB interface. I'll look at doing what
> >you suggest at startup, following a watchdog-generated reset.
>
> Yes, I think the best thing is to do some delay before the USB port
is
> initialized (possibly with "forced" disabling of the USB port by
switching
> the transistor driving the pull up resistor "manually" off during
this time).
>
> >If the "disconnect time is simply too short to be recognized by the
> >host", why would the host stop polling ? Presumably, there is some
> >form of timeout after which the host gives up ? I'll need to dig
out
> >that USB spec again !!!
>
> Huh, don't ask me - I've successfully avoided reading that 1000+
pages
> stuff until now, and I hope I can avoid it in future as well ;-)
>
> I think as long as you have a long enough disconnect time and then
freshly
> start the USB "driver" nothing bad should happen.
>
> >I'm still concerned though that the difference exists between the
two
> >types of reset. As I said in the oirginal post, an external
hardware
> >reset appears to work every time. I'll have a look at how long the
> >two types of reset last.
>
> As far as I know, there is no difference, but usually you have a
much
> longer hard reset time.
>
> Regards
> Herbert
>
> >Regards,
> >
> >David.
> >
> >--- In l...,
Herbert
> >Demmel wrote:
> > >
> > > David,
> > >
> > > as far as I've seen, you can solve that problem by disabling the
> >USB port
> > > (via diabling the pullup resistor driven byP0.31/CONNECT) before
> >your let
> > > the wathdog restart, wait a while and do the reboot then.
> > >
> > > I assume the disconnect time is simply too short to be
recognized
> >by the
> > > host. A different approach would be to wait some time on power
up
> >until you
> > > enable the pullup resistor to have the required disconnect time
> >(about 100
> > > or 200 ms as far as I know).
> > >
> > > Herbert
> > >
> > > At 15:15 09.01.2007 +0000, you wrote:
> > >
> > > >Does anyone have any information or experience of the above ?
> > > >
> > > >I'm using Keil RealView on a custom LPC214x board.
> > > >
> > > >I've noticed that, following a watchdog reset, the USB doesn't
> >always
> > > >appear to come up properly, whereas following an external
reset it
> > > >consistently does.
> > > >
> > > >Using the (somewhat modified) sample USB HID project, about
50% of
> >the
> > > >time the USB interface comes up and Windows starts polling the
> >device
> > > >(GetHIDReports). The other 50%, the USB interface appears to
come
> >up (in
> > > >that I can see the USB descriptors), but there is apparently no
> >polling
> > > >from the host. This only happens following a watchdog reset.
> >Following an
> > > >external reset, it works as expected every time.
> > > >
> > > >Using a software-based USB Analyser (BusHound), it would appear
> >that
> > > >sometimes there is no reset on the USB bus following the
watchdog
> >reset.
> > > >Sometimes there is, but it is delayed by a second or two from
the
> >watchdog
> > > >reset. I haven't observed any consistent correlation between
this
> >and the
> > > >subsequent polling (or lack of) from the host.
> > > >
> > > >Any ideas/suggestions ?
> > > >
> > > >David.
>
> Start a New Thread