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.
Re: LPC2148 - Differences between external reset and internal (watchdog) reset ?
Started by ●January 10, 2007
Reply by ●January 10, 20072007-01-10
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.
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.
Reply by ●January 11, 20072007-01-11
Hi David,
At 16:52 11.01.2007 +0000, you wrote:
>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 ?
I really do not know, how many volts come through to the controller,
as we drive a LCD and zapping is done to the LCD, as this is the only
part visible on the case. I was not aware of the possible situation
that the watchdog hits but the chips does not come up afterwards.
If the controller is alive again (after a reset) the backlight of the
LCD is turned on, which is not the case 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.
Yes, this was already my idea in the meantime. As I have to make a
redesign anyway because the customer claims that my circuit has to
work "with any USB hub on the whole world" and some of them attach
the power supply very slow, I do not get a clean reset in that case
(it's made via a R/C), so I do have to add an external power
supervisory, as the customer is not willing to specify the maximum
rise time of the power supply - "it must work with any USB hub" ... :-((
> I haven't done H/W design in a very long time so
>can't suggest any specific parts.
No problem, I will find something. Thank's for the good intention.
>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.
You are welcome. If you have the time (and like to study tons of
spec) you may have a look at the USB spec to find out, how long this
time must be as per spec. If you find it out, please let me knwo (I
myself try to avoid to read the 1000+ pages).
>There doesn't seem to be a need to explicitly disable the pullup
>resistor as I believe this is done by the reset mechanism.
Ah, good to know, I suggested it, but I was not really sure that it
is done by the reset mechanism.
Regards
Herbert
>--- 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.
> >
At 16:52 11.01.2007 +0000, you wrote:
>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 ?
I really do not know, how many volts come through to the controller,
as we drive a LCD and zapping is done to the LCD, as this is the only
part visible on the case. I was not aware of the possible situation
that the watchdog hits but the chips does not come up afterwards.
If the controller is alive again (after a reset) the backlight of the
LCD is turned on, which is not the case 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.
Yes, this was already my idea in the meantime. As I have to make a
redesign anyway because the customer claims that my circuit has to
work "with any USB hub on the whole world" and some of them attach
the power supply very slow, I do not get a clean reset in that case
(it's made via a R/C), so I do have to add an external power
supervisory, as the customer is not willing to specify the maximum
rise time of the power supply - "it must work with any USB hub" ... :-((
> I haven't done H/W design in a very long time so
>can't suggest any specific parts.
No problem, I will find something. Thank's for the good intention.
>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.
You are welcome. If you have the time (and like to study tons of
spec) you may have a look at the USB spec to find out, how long this
time must be as per spec. If you find it out, please let me knwo (I
myself try to avoid to read the 1000+ pages).
>There doesn't seem to be a need to explicitly disable the pullup
>resistor as I believe this is done by the reset mechanism.
Ah, good to know, I suggested it, but I was not really sure that it
is done by the reset mechanism.
Regards
Herbert
>--- 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.
> >
