EmbeddedRelated.com
Forums
Memfault State of IoT Report

Re: Code Warrior and BDM Multilink Reset and BKGD Timing

Started by Kevin Antony May 18, 2005
We had this exact situation with our system basis chip (MC33989) watchdog
resetting the processor during debugging with P&Es BDM Multilink. We simply
placed a large resistor (100K) between the reset chip and HC12/BDM reset
line. It allows the BDM pod to "overdrive" whatever the reset chip is
trying to do during debugging and with the BDM pod disconnected the reset
chip can still reset the processor through the resistor. This may be an
easy rework to your production pcb - depending on layout.

Kevin -----Original Message-----
From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf Of
eric_cina
Sent: Wednesday, May 18, 2005 10:34 AM
To: 68HC12@68HC...
Subject: [68HC12] Code Warrior and BDM Multilink Reset and BKGD Timing Hi,

I am using the USB BDM Multilink with CodeWarrior. On a reset, the BDM
pulls the RESET low for 5 ms and pulls the BKGD low for 10 ms to put
the target into background mode. My target has a reset chip which
debounces the RESET signal and its essentially keeping the RESET low
for 700 ms. At this time, the BKGD is not low and my target will not
enter background mode.

I cannot change the reset chip or the target board as this has been in
production for several years already. I would like to change the
timing sequence on the BDM to extend the amount of time the BKGD is
held low. Can this be done using CodeWarrior? How can I do it?

Any suggestions would be appreciated.

Thanks,
Eric


Hi,

I am using the USB BDM Multilink with CodeWarrior. On a reset, the BDM
pulls the RESET low for 5 ms and pulls the BKGD low for 10 ms to put
the target into background mode. My target has a reset chip which
debounces the RESET signal and its essentially keeping the RESET low
for 700 ms. At this time, the BKGD is not low and my target will not
enter background mode.

I cannot change the reset chip or the target board as this has been in
production for several years already. I would like to change the
timing sequence on the BDM to extend the amount of time the BKGD is
held low. Can this be done using CodeWarrior? How can I do it?

Any suggestions would be appreciated.

Thanks,
Eric



We actually have a HW work around for our new target boards but our
old ones are not going to change.

A SW/FW solution would be ideal. So I would still like to know how,
if possible, to modify this BDM Reset Timing using CodeWarrior.

Thanks,
Eric
--- In 68HC12@68HC..., "Kevin Antony" <kevin.antony@a...>
wrote:
> We had this exact situation with our system basis chip (MC33989)
watchdog
> resetting the processor during debugging with P&Es BDM Multilink.
We simply
> placed a large resistor (100K) between the reset chip and HC12/BDM
reset
> line. It allows the BDM pod to "overdrive" whatever the reset
chip is
> trying to do during debugging and with the BDM pod disconnected
the reset
> chip can still reset the processor through the resistor. This may
be an
> easy rework to your production pcb - depending on layout.
>
> Kevin > -----Original Message-----
> From: 68HC12@68HC... [mailto:68HC12@68HC...] On
Behalf Of
> eric_cina
> Sent: Wednesday, May 18, 2005 10:34 AM
> To: 68HC12@68HC...
> Subject: [68HC12] Code Warrior and BDM Multilink Reset and BKGD
Timing
>
>
> Hi,
>
> I am using the USB BDM Multilink with CodeWarrior. On a reset, the
BDM
> pulls the RESET low for 5 ms and pulls the BKGD low for 10 ms to
put
> the target into background mode. My target has a reset chip which
> debounces the RESET signal and its essentially keeping the RESET
low
> for 700 ms. At this time, the BKGD is not low and my target will
not
> enter background mode.
>
> I cannot change the reset chip or the target board as this has
been in
> production for several years already. I would like to change the
> timing sequence on the BDM to extend the amount of time the BKGD
is
> held low. Can this be done using CodeWarrior? How can I do it?
>
> Any suggestions would be appreciated.
>
> Thanks,
> Eric >
>



Memfault State of IoT Report