Hi,
me and my research group are working towards developing a hybrid
vehicle, where the electric powertrain is driven by a 56F8323 Freescale
DSC.
We frequently have to reprogram the DSC, and once in about ten or twenty
reprograms the DSC would stop working and give "Core not responding" and
"Failed to write to FLASH" errors; at this point the only remedy is to
replace the DSC (DSC fried). Anyone experienced the same problem?
I don't know why this happens, we think some weird ground loop but how?
The vehicle is battery operated and when we program the DSC it sits on a
bench isolated from ground...
Then a colleague brought us an optoisolated programmer like this one:
http://cgi.ebay.it/ws/eBayISAPI.dll?ViewItem&item20296958416&ssPageNameME:L:LCA:IT:1123
with this programmer it's been two days without problems! It works
great. This confirms the ground loop hypothesis.
Freescale used to sell optoisolated programmers but now they don't sell
them anymore. I think this is the only optoisolated programmer for
Freescale DSC on the market. We already contacted the manufacturers to
buy one.
Anyone had similar problems? Any thoughts?
Regards,
-- Carlo.
Re: DSP fried - Solved with optoisolated programmer
Started by ●September 10, 2008
Reply by ●September 10, 20082008-09-10
Hi,
One of the issues possible is to make sure that you have a weak pull down for each of the PWM lines.This may not be the fix for the problem if you already have one but it is likely that the PWM signals(both high and low side) may go logic high at the time of programming as the controller treats them as GPIO.Have you probed the PWM signals at the time of reprogramming ?
Regards
Prasanna
--- On Wed, 9/10/08, Carlo wrote:
> From: Carlo
> Subject: [motoroladsp] Re: DSP fried - Solved with optoisolated programmer
> To: m...
> Date: Wednesday, September 10, 2008, 3:23 PM
> Hi,
>
> me and my research group are working towards developing a
> hybrid
> vehicle, where the electric powertrain is driven by a
> 56F8323 Freescale
> DSC.
> We frequently have to reprogram the DSC, and once in about
> ten or twenty
> reprograms the DSC would stop working and give "Core
> not responding" and
> "Failed to write to FLASH" errors; at this point
> the only remedy is to
> replace the DSC (DSC fried). Anyone experienced the same
> problem?
>
> I don't know why this happens, we think some weird
> ground loop but how?
> The vehicle is battery operated and when we program the DSC
> it sits on a
> bench isolated from ground...
> Then a colleague brought us an optoisolated programmer like
> this one:
>
> http://cgi.ebay.it/ws/eBayISAPI.dll?ViewItem&item20296958416&ssPageNameME:L:LCA:IT:1123
> with this programmer it's been two days without
> problems! It works
> great. This confirms the ground loop hypothesis.
> Freescale used to sell optoisolated programmers but now
> they don't sell
> them anymore. I think this is the only optoisolated
> programmer for
> Freescale DSC on the market. We already contacted the
> manufacturers to
> buy one.
>
> Anyone had similar problems? Any thoughts?
>
> Regards,
> -- Carlo.
One of the issues possible is to make sure that you have a weak pull down for each of the PWM lines.This may not be the fix for the problem if you already have one but it is likely that the PWM signals(both high and low side) may go logic high at the time of programming as the controller treats them as GPIO.Have you probed the PWM signals at the time of reprogramming ?
Regards
Prasanna
--- On Wed, 9/10/08, Carlo wrote:
> From: Carlo
> Subject: [motoroladsp] Re: DSP fried - Solved with optoisolated programmer
> To: m...
> Date: Wednesday, September 10, 2008, 3:23 PM
> Hi,
>
> me and my research group are working towards developing a
> hybrid
> vehicle, where the electric powertrain is driven by a
> 56F8323 Freescale
> DSC.
> We frequently have to reprogram the DSC, and once in about
> ten or twenty
> reprograms the DSC would stop working and give "Core
> not responding" and
> "Failed to write to FLASH" errors; at this point
> the only remedy is to
> replace the DSC (DSC fried). Anyone experienced the same
> problem?
>
> I don't know why this happens, we think some weird
> ground loop but how?
> The vehicle is battery operated and when we program the DSC
> it sits on a
> bench isolated from ground...
> Then a colleague brought us an optoisolated programmer like
> this one:
>
> http://cgi.ebay.it/ws/eBayISAPI.dll?ViewItem&item20296958416&ssPageNameME:L:LCA:IT:1123
> with this programmer it's been two days without
> problems! It works
> great. This confirms the ground loop hypothesis.
> Freescale used to sell optoisolated programmers but now
> they don't sell
> them anymore. I think this is the only optoisolated
> programmer for
> Freescale DSC on the market. We already contacted the
> manufacturers to
> buy one.
>
> Anyone had similar problems? Any thoughts?
>
> Regards,
> -- Carlo.
Reply by ●September 11, 20082008-09-11
Prasanna Nambi wrote:
> Hi,
> One of the issues possible is to make sure that you have a weak pull down for each of the PWM lines.This may not be the fix for the problem if you already have one but it is likely that the PWM signals(both high and low side) may go logic high at the time of programming as the controller treats them as GPIO.Have you probed the PWM signals at the time of reprogramming ?
Hi,
I don't think the problem comes from the PWM signals because the power bus is
disconnected during programming and the only damaged component is the DSC.
Best regards,
Carlo.
> Hi,
> One of the issues possible is to make sure that you have a weak pull down for each of the PWM lines.This may not be the fix for the problem if you already have one but it is likely that the PWM signals(both high and low side) may go logic high at the time of programming as the controller treats them as GPIO.Have you probed the PWM signals at the time of reprogramming ?
Hi,
I don't think the problem comes from the PWM signals because the power bus is
disconnected during programming and the only damaged component is the DSC.
Best regards,
Carlo.
Reply by ●September 11, 20082008-09-11
Hi Carlo,
I am using the MC56F8367. When I started using the device, I created
structures for addressing the hardware registers of the peripherals
directly. After some playing around with the lincer command file I
finally got it running on the Freescale DemoBoard. But when I
downloaded the code to my hardware, I also received the message: Core
not responding. In my case the problem was that the CodeWarrior
software automatically initialise ALL variables to zero: In this case
also ALL the DSP Registers! I could not prevent the software from
doing it - even after commenting out the ZERO_BSS subroutine. Now I
am using pointers to structures for addressing the registers and it
works fine. No "core not responding" messages anymore.
So I suggest that you look at the initialising of the clocks and PLL
etc. Also at the implementation of your reset circuitry.
Another question: Do you have a watchdog enabled? Is your watchdog
disabled when you try to download new code? A watchdog reset will
definitely also cause a "Core Not Responding" error.
Regards
Adam Barnard
--- In m..., Carlo wrote:
>
> Hi,
>
> me and my research group are working towards developing a hybrid
> vehicle, where the electric powertrain is driven by a 56F8323
Freescale
> DSC.
> We frequently have to reprogram the DSC, and once in about ten or
twenty
> reprograms the DSC would stop working and give "Core not
responding" and
> "Failed to write to FLASH" errors; at this point the only remedy is
to
> replace the DSC (DSC fried). Anyone experienced the same problem?
>
> I don't know why this happens, we think some weird ground loop but
how?
> The vehicle is battery operated and when we program the DSC it sits
on a
> bench isolated from ground...
> Then a colleague brought us an optoisolated programmer like this
one:
>
> http://cgi.ebay.it/ws/eBayISAPI.dll?
ViewItem&item20296958416&ssPageNameME:L:LCA:IT:1123
>
> with this programmer it's been two days without problems! It works
> great. This confirms the ground loop hypothesis.
> Freescale used to sell optoisolated programmers but now they don't
sell
> them anymore. I think this is the only optoisolated programmer for
> Freescale DSC on the market. We already contacted the manufacturers
to
> buy one.
>
> Anyone had similar problems? Any thoughts?
>
> Regards,
> -- Carlo.
>
I am using the MC56F8367. When I started using the device, I created
structures for addressing the hardware registers of the peripherals
directly. After some playing around with the lincer command file I
finally got it running on the Freescale DemoBoard. But when I
downloaded the code to my hardware, I also received the message: Core
not responding. In my case the problem was that the CodeWarrior
software automatically initialise ALL variables to zero: In this case
also ALL the DSP Registers! I could not prevent the software from
doing it - even after commenting out the ZERO_BSS subroutine. Now I
am using pointers to structures for addressing the registers and it
works fine. No "core not responding" messages anymore.
So I suggest that you look at the initialising of the clocks and PLL
etc. Also at the implementation of your reset circuitry.
Another question: Do you have a watchdog enabled? Is your watchdog
disabled when you try to download new code? A watchdog reset will
definitely also cause a "Core Not Responding" error.
Regards
Adam Barnard
--- In m..., Carlo wrote:
>
> Hi,
>
> me and my research group are working towards developing a hybrid
> vehicle, where the electric powertrain is driven by a 56F8323
Freescale
> DSC.
> We frequently have to reprogram the DSC, and once in about ten or
twenty
> reprograms the DSC would stop working and give "Core not
responding" and
> "Failed to write to FLASH" errors; at this point the only remedy is
to
> replace the DSC (DSC fried). Anyone experienced the same problem?
>
> I don't know why this happens, we think some weird ground loop but
how?
> The vehicle is battery operated and when we program the DSC it sits
on a
> bench isolated from ground...
> Then a colleague brought us an optoisolated programmer like this
one:
>
> http://cgi.ebay.it/ws/eBayISAPI.dll?
ViewItem&item20296958416&ssPageNameME:L:LCA:IT:1123
>
> with this programmer it's been two days without problems! It works
> great. This confirms the ground loop hypothesis.
> Freescale used to sell optoisolated programmers but now they don't
sell
> them anymore. I think this is the only optoisolated programmer for
> Freescale DSC on the market. We already contacted the manufacturers
to
> buy one.
>
> Anyone had similar problems? Any thoughts?
>
> Regards,
> -- Carlo.
>
Reply by ●September 12, 20082008-09-12
Hello Carlo, hello all
as I understood, the C is defective after connection to the programmer.
My suggestion is: there are potential differences (electrostatic charge).
I had following case:
C connected to Ground via Power Supply
Laptop with 2-wire-PowerSupply (no PE -- floating ground and
Y-Capacitors for EMC between power lines and Gnd of laptop).
When connecting to Cs serial line or JTAG-pins with data pins before GND,
the potential difference is discharged through data pins which kills them.
Always be sure to connect gnd FIRST (w.g. via an extra wire).
Good look! Be careful
Klaus from Germany
-----Original Message-----
From: m... [mailto:m...]On Behalf Of adam.barnard_ch
Sent: Thursday, September 11, 2008 8:35 AM
To: m...
Subject: [motoroladsp] Re: DSP fried - Solved with optoisolated programmer
as I understood, the C is defective after connection to the programmer.
My suggestion is: there are potential differences (electrostatic charge).
I had following case:
C connected to Ground via Power Supply
Laptop with 2-wire-PowerSupply (no PE -- floating ground and
Y-Capacitors for EMC between power lines and Gnd of laptop).
When connecting to Cs serial line or JTAG-pins with data pins before GND,
the potential difference is discharged through data pins which kills them.
Always be sure to connect gnd FIRST (w.g. via an extra wire).
Good look! Be careful
Klaus from Germany
-----Original Message-----
From: m... [mailto:m...]On Behalf Of adam.barnard_ch
Sent: Thursday, September 11, 2008 8:35 AM
To: m...
Subject: [motoroladsp] Re: DSP fried - Solved with optoisolated programmer
Reply by ●September 12, 20082008-09-12
adam.barnard_ch wrote:
> Hi Carlo,
>
> I am using the MC56F8367. When I started using the device, I created
> structures for addressing the hardware registers of the peripherals
> directly. After some playing around with the lincer command file I
> finally got it running on the Freescale DemoBoard. But when I
> downloaded the code to my hardware, I also received the message: Core
> not responding. In my case the problem was that the CodeWarrior
> software automatically initialise ALL variables to zero: In this case
> also ALL the DSP Registers! I could not prevent the software from
> doing it - even after commenting out the ZERO_BSS subroutine. Now I
> am using pointers to structures for addressing the registers and it
> works fine. No "core not responding" messages anymore.
Could you program the DSC after this happened? We had to REPLACE it
(desolder/solder a new one) every time because it wouldn't respond anymore,
even after power cycling and some cooling; and it happened randomly once in a
couple of days or so (we have a stock of a dozen devices).
> So I suggest that you look at the initialising of the clocks and PLL
> etc. Also at the implementation of your reset circuitry.
>
> Another question: Do you have a watchdog enabled? Is your watchdog
> disabled when you try to download new code? A watchdog reset will
> definitely also cause a "Core Not Responding" error.
Watchdog disabled; as far as I know reset circuitry is as found on the data sheet.
Thanks for the reply and best regards,
Carlo.
> --- In m...
> , Carlo wrote:
> >
> > Hi,
> >
> > me and my research group are working towards developing a hybrid
> > vehicle, where the electric powertrain is driven by a 56F8323
> Freescale
> > DSC.
> > We frequently have to reprogram the DSC, and once in about ten or
> twenty
> > reprograms the DSC would stop working and give "Core not
> responding" and
> > "Failed to write to FLASH" errors; at this point the only remedy is
> to
> > replace the DSC (DSC fried). Anyone experienced the same problem?
> >
> > I don't know why this happens, we think some weird ground loop but
> how?
> > The vehicle is battery operated and when we program the DSC it sits
> on a
> > bench isolated from ground...
> > Then a colleague brought us an optoisolated programmer like this
> one:
> >
> > http://cgi.ebay.it/ws/eBayISAPI.dll?
>
> ViewItem&item20296958416&ssPageNameME:L:LCA:IT:1123
> >
> >
> >
> > with this programmer it's been two days without problems! It works
> > great. This confirms the ground loop hypothesis.
> > Freescale used to sell optoisolated programmers but now they don't
> sell
> > them anymore. I think this is the only optoisolated programmer for
> > Freescale DSC on the market. We already contacted the manufacturers
> to
> > buy one.
> >
> > Anyone had similar problems? Any thoughts?
> >
> > Regards,
> > -- Carlo.
> >
> Hi Carlo,
>
> I am using the MC56F8367. When I started using the device, I created
> structures for addressing the hardware registers of the peripherals
> directly. After some playing around with the lincer command file I
> finally got it running on the Freescale DemoBoard. But when I
> downloaded the code to my hardware, I also received the message: Core
> not responding. In my case the problem was that the CodeWarrior
> software automatically initialise ALL variables to zero: In this case
> also ALL the DSP Registers! I could not prevent the software from
> doing it - even after commenting out the ZERO_BSS subroutine. Now I
> am using pointers to structures for addressing the registers and it
> works fine. No "core not responding" messages anymore.
Could you program the DSC after this happened? We had to REPLACE it
(desolder/solder a new one) every time because it wouldn't respond anymore,
even after power cycling and some cooling; and it happened randomly once in a
couple of days or so (we have a stock of a dozen devices).
> So I suggest that you look at the initialising of the clocks and PLL
> etc. Also at the implementation of your reset circuitry.
>
> Another question: Do you have a watchdog enabled? Is your watchdog
> disabled when you try to download new code? A watchdog reset will
> definitely also cause a "Core Not Responding" error.
Watchdog disabled; as far as I know reset circuitry is as found on the data sheet.
Thanks for the reply and best regards,
Carlo.
> --- In m...
> , Carlo wrote:
> >
> > Hi,
> >
> > me and my research group are working towards developing a hybrid
> > vehicle, where the electric powertrain is driven by a 56F8323
> Freescale
> > DSC.
> > We frequently have to reprogram the DSC, and once in about ten or
> twenty
> > reprograms the DSC would stop working and give "Core not
> responding" and
> > "Failed to write to FLASH" errors; at this point the only remedy is
> to
> > replace the DSC (DSC fried). Anyone experienced the same problem?
> >
> > I don't know why this happens, we think some weird ground loop but
> how?
> > The vehicle is battery operated and when we program the DSC it sits
> on a
> > bench isolated from ground...
> > Then a colleague brought us an optoisolated programmer like this
> one:
> >
> > http://cgi.ebay.it/ws/eBayISAPI.dll?
>
> ViewItem&item20296958416&ssPageNameME:L:LCA:IT:1123
> >
> >
> >
> > with this programmer it's been two days without problems! It works
> > great. This confirms the ground loop hypothesis.
> > Freescale used to sell optoisolated programmers but now they don't
> sell
> > them anymore. I think this is the only optoisolated programmer for
> > Freescale DSC on the market. We already contacted the manufacturers
> to
> > buy one.
> >
> > Anyone had similar problems? Any thoughts?
> >
> > Regards,
> > -- Carlo.
> >
Reply by ●September 12, 20082008-09-12
I agree 100% with Weber Klaus, who states the problem very clearly. To put some
more words around
it there is a serious electrical hazard problem with many (if not all) laptop power supplies. At
least here in the States, the safety authorities (UL, CE) dont require that a three-wire grounding
plug is used. Within the laptop power supply brick there is usually a line-switched power supply.
For EMC reasons they typically connect a high-voltage Y capacitor from the secondary to the primary.
This capacitor breaks the isolation barrier as between the AC line (mains) voltage, and the laptop
digital ground. This capacitor has a relatively high impedance at power frequencies (50/60 Hz) but
still allows some AC voltage leakage. There isnt enough current to electrocute a person, which is
enough to satisfy the safety authorities. But the leakage voltage is high enough to damage a lot of
equipment.
We recently did the following measurement on one of our laptops. Plugged it into its brick power
supply, which plugs into the power line using a two-wire AC plug. AC voltage at the receptacle was
120 VAC. Measured the AC voltage from the laptop digital ground (USB shell) to either receptacle
neutral or ground, and measured 57 VAC. (This is typical, but the exact amount will vary for
different laptop/power supply combinations.)
Once the USB port (laptop digital ground) is connected to a piece of equipment whose digital ground
is connected to building ground (such as a desktop PC), the two grounds come into equilibrium. At
that point we measure 45 microamps of AC leakage current flowing between the two grounds.
On this laptop/power supply combination, we used a peak-reading meter and measured up to 75
microamps peak current at the moment when laptop digital ground was connected to building ground.
So when the laptop is connected via USB cable to an MCU programmer, and that programmer is connected
to your development board via JTAG or BDM, at time of initial connection you can be connecting 57
VAC (or whatever specific voltage for your laptop/power supply) into your processor circuit.
Weve seen lots of problems with USB (and RS-232 also) when connecting a laptop serial interface to
a piece of properly grounded equipment. The problem doesnt typically happen with desktops because
they are usually grounded properly.
So
1. Dont use a laptop.
2. Or, if you do use a laptop, make a bonding strap from the laptop digital ground (USB ground) to
building ground, and make sure the bonding strap is connected before connecting the programmer. Or,
use a proper three-wire grounding AC cord to connect to the laptop power supply AC two-wire input,
and run the third (grounding) wire in the power cord around the brick to the laptop digital ground.
3. Use an isolated programmer, as others have suggested.
4. The engineering community might want to lobby the electrical certification authorities with the
message that two-wire power supplies for laptops arent really safe well, they probably wont
electrocute anybody but they are destroying many thousands of dollars of equipment that they
interconnect to, every year.
Best regards,
Kerry Berland
k...@siliconengines.net
Silicon Engines
3550 West Salt Creek Lane
Suite 105
Arlington Heights, IL 60005 USA
Phone 847-637-1180 Ext. 223
Fax 847-637-1185
Mobile 847-337-5617
www.siliconengines.net
From: m... [mailto:m...] On Behalf Of Weber Klaus
Sent: Friday, September 12, 2008 7:22 AM
To: adam.barnard_ch; m...
Subject: RE: [motoroladsp] Re: DSP fried - Solved with optoisolated programmer
Hello Carlo, hello all
as I understood, the C is defective after connection to the programmer.
My suggestion is: there are potential differences (electrostatic charge).
I had following case:
C connected to Ground via Power Supply
Laptop with 2-wire-PowerSupply (no PE -- floating ground and
Y-Capacitors for EMC between power lines and Gnd of laptop).
When connecting to Cs serial line or JTAG-pins with data pins before GND,
the potential difference is discharged through data pins which kills them.
Always be sure to connect gnd FIRST (w.g. via an extra wire).
Good look! Be careful
Klaus from Germany
-----Original Message-----
From: m...
[mailto:m... ]On Behalf Of
adam.barnard_ch
Sent: Thursday, September 11, 2008 8:35 AM
To: m...
Subject: [motoroladsp] Re: DSP fried - Solved with optoisolated programmer
it there is a serious electrical hazard problem with many (if not all) laptop power supplies. At
least here in the States, the safety authorities (UL, CE) dont require that a three-wire grounding
plug is used. Within the laptop power supply brick there is usually a line-switched power supply.
For EMC reasons they typically connect a high-voltage Y capacitor from the secondary to the primary.
This capacitor breaks the isolation barrier as between the AC line (mains) voltage, and the laptop
digital ground. This capacitor has a relatively high impedance at power frequencies (50/60 Hz) but
still allows some AC voltage leakage. There isnt enough current to electrocute a person, which is
enough to satisfy the safety authorities. But the leakage voltage is high enough to damage a lot of
equipment.
We recently did the following measurement on one of our laptops. Plugged it into its brick power
supply, which plugs into the power line using a two-wire AC plug. AC voltage at the receptacle was
120 VAC. Measured the AC voltage from the laptop digital ground (USB shell) to either receptacle
neutral or ground, and measured 57 VAC. (This is typical, but the exact amount will vary for
different laptop/power supply combinations.)
Once the USB port (laptop digital ground) is connected to a piece of equipment whose digital ground
is connected to building ground (such as a desktop PC), the two grounds come into equilibrium. At
that point we measure 45 microamps of AC leakage current flowing between the two grounds.
On this laptop/power supply combination, we used a peak-reading meter and measured up to 75
microamps peak current at the moment when laptop digital ground was connected to building ground.
So when the laptop is connected via USB cable to an MCU programmer, and that programmer is connected
to your development board via JTAG or BDM, at time of initial connection you can be connecting 57
VAC (or whatever specific voltage for your laptop/power supply) into your processor circuit.
Weve seen lots of problems with USB (and RS-232 also) when connecting a laptop serial interface to
a piece of properly grounded equipment. The problem doesnt typically happen with desktops because
they are usually grounded properly.
So
1. Dont use a laptop.
2. Or, if you do use a laptop, make a bonding strap from the laptop digital ground (USB ground) to
building ground, and make sure the bonding strap is connected before connecting the programmer. Or,
use a proper three-wire grounding AC cord to connect to the laptop power supply AC two-wire input,
and run the third (grounding) wire in the power cord around the brick to the laptop digital ground.
3. Use an isolated programmer, as others have suggested.
4. The engineering community might want to lobby the electrical certification authorities with the
message that two-wire power supplies for laptops arent really safe well, they probably wont
electrocute anybody but they are destroying many thousands of dollars of equipment that they
interconnect to, every year.
Best regards,
Kerry Berland
k...@siliconengines.net
Silicon Engines
3550 West Salt Creek Lane
Suite 105
Arlington Heights, IL 60005 USA
Phone 847-637-1180 Ext. 223
Fax 847-637-1185
Mobile 847-337-5617
www.siliconengines.net
From: m... [mailto:m...] On Behalf Of Weber Klaus
Sent: Friday, September 12, 2008 7:22 AM
To: adam.barnard_ch; m...
Subject: RE: [motoroladsp] Re: DSP fried - Solved with optoisolated programmer
Hello Carlo, hello all
as I understood, the C is defective after connection to the programmer.
My suggestion is: there are potential differences (electrostatic charge).
I had following case:
C connected to Ground via Power Supply
Laptop with 2-wire-PowerSupply (no PE -- floating ground and
Y-Capacitors for EMC between power lines and Gnd of laptop).
When connecting to Cs serial line or JTAG-pins with data pins before GND,
the potential difference is discharged through data pins which kills them.
Always be sure to connect gnd FIRST (w.g. via an extra wire).
Good look! Be careful
Klaus from Germany
-----Original Message-----
From: m...
[mailto:m... ]On Behalf Of
adam.barnard_ch
Sent: Thursday, September 11, 2008 8:35 AM
To: m...
Subject: [motoroladsp] Re: DSP fried - Solved with optoisolated programmer
Reply by ●September 13, 20082008-09-13
It could get even worse.
Here in the USA, my company does fire alarm system work, and we have been using laptops to upload/download configuration files from/to fire alarm panel motherboards, which are microcontroller based. We have been using RS-232 ports without any serious issues.
Recently our manufacturer started putting USB ports on some of the newer systems, and one of our technicians tried to use this method for connecting to a motherboard.
There was a "ground" (accidental connection of peripheral wiring--we call it field wiring--to the building electrical conduit/grounding system) on some wiring connected to the fire alarm motherboard. Usually this is not a problem--fire alarm systems are made to tolerate "grounds" of this type, although it is considered a fault or off-normal condition.
Anyway, the combination of the "grounded wiring" and using the USB port fried the laptop!!
We're talking serious damage here. We were hoping we could salvage the hard drive contents by using one of those hard drive recovery services, but the laptop itself was toast!!!
--- On Fri, 9/12/08, Kerry Berland wrote:
From: Kerry Berland
Subject: RE: [motoroladsp] Re: DSP fried - Solved with optoisolated programmer
To: "'Weber Klaus'" , "'adam.barnard_ch'" , m...
Date: Friday, September 12, 2008, 6:33 PM
I agree 100% with Weber Klaus, who states the problem very clearly. To put some more words around
it there is a serious electrical hazard problem with many (if not all) laptop power supplies. At
least here in the States, the safety authorities (UL, CE) dont require that a three-wire grounding
plug is used. Within the laptop power supply brick there is usually a line-switched power supply.
For EMC reasons they typically connect a high-voltage Y capacitor from the secondary to the primary.
This capacitor breaks the isolation barrier as between the AC line (mains) voltage, and the laptop
digital ground. This capacitor has a relatively high impedance at power frequencies (50/60 Hz) but
still allows some AC voltage leakage. There isnt enough current to electrocute a person, which is
enough to satisfy the safety authorities. But the leakage voltage is high enough to damage a lot of
equipment.
We recently did the following measurement on one of our laptops. Plugged it into its brick power
supply, which plugs into the power line using a two-wire AC plug. AC voltage at the receptacle was
120 VAC. Measured the AC voltage from the laptop digital ground (USB shell) to either receptacle
neutral or ground, and measured 57 VAC. (This is typical, but the exact amount will vary for
different laptop/power supply combinations. )
Once the USB port (laptop digital ground) is connected to a piece of equipment whose digital ground
is connected to building ground (such as a desktop PC), the two grounds come into equilibrium. At
that point we measure 45 microamps of AC leakage current flowing between the two grounds.
On this laptop/power supply combination, we used a peak-reading meter and measured up to 75
microamps peak current at the moment when laptop digital ground was connected to building ground.
So when the laptop is connected via USB cable to an MCU programmer, and that programmer is connected
to your development board via JTAG or BDM, at time of initial connection you can be connecting 57
VAC (or whatever specific voltage for your laptop/power supply) into your processor circuit.
Weve seen lots of problems with USB (and RS-232 also) when connecting a laptop serial interface to
a piece of properly grounded equipment. The problem doesnt typically happen with desktops because
they are usually grounded properly.
So
1. Dont use a laptop.
2. Or, if you do use a laptop, make a bonding strap from the laptop digital ground (USB ground) to
building ground, and make sure the bonding strap is connected before connecting the programmer. Or,
use a proper three-wire grounding AC cord to connect to the laptop power supply AC two-wire input,
and run the third (grounding) wire in the power cord around the brick to the laptop digital ground.
3. Use an isolated programmer, as others have suggested.
4. The engineering community might want to lobby the electrical certification authorities with the
message that two-wire power supplies for laptops arent really safe well, they probably wont
electrocute anybody but they are destroying many thousands of dollars of equipment that they
interconnect to, every year.
Best regards,
Kerry Berland
kerry.berland@ siliconengines. net
Silicon Engines
3550 West Salt Creek Lane
Suite 105
Arlington Heights, IL 60005 USA
Phone 847-637-1180 Ext. 223
Fax 847-637-1185
Mobile 847-337-5617
www.siliconengines. net
From: motoroladsp@ yahoogroups. com [mailto:motoroladsp@ yahoogroups. com] On Behalf Of Weber Klaus
Sent: Friday, September 12, 2008 7:22 AM
To: adam.barnard_ ch; motoroladsp@ yahoogroups. com
Subject: RE: [motoroladsp] Re: DSP fried - Solved with optoisolated programmer
Hello Carlo, hello all
as I understood, the C is defective after connection to the programmer.
My suggestion is: there are potential differences (electrostatic charge).
I had following case:
C connected to Ground via Power Supply
Laptop with 2-wire-PowerSupply (no PE -- floating ground and
Y-Capacitors for EMC between power lines and Gnd of laptop).
When connecting to Cs serial line or JTAG-pins with data pins before GND,
the potential difference is discharged through data pins which kills them.
Always be sure to connect gnd FIRST (w.g. via an extra wire).
Good look! Be careful
Klaus from Germany
-----Original Message-----
From: motoroladsp@ yahoogroups. com
[mailto:motoroladsp@ yahoogroups. com ]On Behalf Of
adam.barnard_ ch
Sent: Thursday, September 11, 2008 8:35 AM
To: motoroladsp@ yahoogroups. com
Subject: [motoroladsp] Re: DSP fried - Solved with optoisolated programmer
Here in the USA, my company does fire alarm system work, and we have been using laptops to upload/download configuration files from/to fire alarm panel motherboards, which are microcontroller based. We have been using RS-232 ports without any serious issues.
Recently our manufacturer started putting USB ports on some of the newer systems, and one of our technicians tried to use this method for connecting to a motherboard.
There was a "ground" (accidental connection of peripheral wiring--we call it field wiring--to the building electrical conduit/grounding system) on some wiring connected to the fire alarm motherboard. Usually this is not a problem--fire alarm systems are made to tolerate "grounds" of this type, although it is considered a fault or off-normal condition.
Anyway, the combination of the "grounded wiring" and using the USB port fried the laptop!!
We're talking serious damage here. We were hoping we could salvage the hard drive contents by using one of those hard drive recovery services, but the laptop itself was toast!!!
--- On Fri, 9/12/08, Kerry Berland wrote:
From: Kerry Berland
Subject: RE: [motoroladsp] Re: DSP fried - Solved with optoisolated programmer
To: "'Weber Klaus'" , "'adam.barnard_ch'" , m...
Date: Friday, September 12, 2008, 6:33 PM
I agree 100% with Weber Klaus, who states the problem very clearly. To put some more words around
it there is a serious electrical hazard problem with many (if not all) laptop power supplies. At
least here in the States, the safety authorities (UL, CE) dont require that a three-wire grounding
plug is used. Within the laptop power supply brick there is usually a line-switched power supply.
For EMC reasons they typically connect a high-voltage Y capacitor from the secondary to the primary.
This capacitor breaks the isolation barrier as between the AC line (mains) voltage, and the laptop
digital ground. This capacitor has a relatively high impedance at power frequencies (50/60 Hz) but
still allows some AC voltage leakage. There isnt enough current to electrocute a person, which is
enough to satisfy the safety authorities. But the leakage voltage is high enough to damage a lot of
equipment.
We recently did the following measurement on one of our laptops. Plugged it into its brick power
supply, which plugs into the power line using a two-wire AC plug. AC voltage at the receptacle was
120 VAC. Measured the AC voltage from the laptop digital ground (USB shell) to either receptacle
neutral or ground, and measured 57 VAC. (This is typical, but the exact amount will vary for
different laptop/power supply combinations. )
Once the USB port (laptop digital ground) is connected to a piece of equipment whose digital ground
is connected to building ground (such as a desktop PC), the two grounds come into equilibrium. At
that point we measure 45 microamps of AC leakage current flowing between the two grounds.
On this laptop/power supply combination, we used a peak-reading meter and measured up to 75
microamps peak current at the moment when laptop digital ground was connected to building ground.
So when the laptop is connected via USB cable to an MCU programmer, and that programmer is connected
to your development board via JTAG or BDM, at time of initial connection you can be connecting 57
VAC (or whatever specific voltage for your laptop/power supply) into your processor circuit.
Weve seen lots of problems with USB (and RS-232 also) when connecting a laptop serial interface to
a piece of properly grounded equipment. The problem doesnt typically happen with desktops because
they are usually grounded properly.
So
1. Dont use a laptop.
2. Or, if you do use a laptop, make a bonding strap from the laptop digital ground (USB ground) to
building ground, and make sure the bonding strap is connected before connecting the programmer. Or,
use a proper three-wire grounding AC cord to connect to the laptop power supply AC two-wire input,
and run the third (grounding) wire in the power cord around the brick to the laptop digital ground.
3. Use an isolated programmer, as others have suggested.
4. The engineering community might want to lobby the electrical certification authorities with the
message that two-wire power supplies for laptops arent really safe well, they probably wont
electrocute anybody but they are destroying many thousands of dollars of equipment that they
interconnect to, every year.
Best regards,
Kerry Berland
kerry.berland@ siliconengines. net
Silicon Engines
3550 West Salt Creek Lane
Suite 105
Arlington Heights, IL 60005 USA
Phone 847-637-1180 Ext. 223
Fax 847-637-1185
Mobile 847-337-5617
www.siliconengines. net
From: motoroladsp@ yahoogroups. com [mailto:motoroladsp@ yahoogroups. com] On Behalf Of Weber Klaus
Sent: Friday, September 12, 2008 7:22 AM
To: adam.barnard_ ch; motoroladsp@ yahoogroups. com
Subject: RE: [motoroladsp] Re: DSP fried - Solved with optoisolated programmer
Hello Carlo, hello all
as I understood, the C is defective after connection to the programmer.
My suggestion is: there are potential differences (electrostatic charge).
I had following case:
C connected to Ground via Power Supply
Laptop with 2-wire-PowerSupply (no PE -- floating ground and
Y-Capacitors for EMC between power lines and Gnd of laptop).
When connecting to Cs serial line or JTAG-pins with data pins before GND,
the potential difference is discharged through data pins which kills them.
Always be sure to connect gnd FIRST (w.g. via an extra wire).
Good look! Be careful
Klaus from Germany
-----Original Message-----
From: motoroladsp@ yahoogroups. com
[mailto:motoroladsp@ yahoogroups. com ]On Behalf Of
adam.barnard_ ch
Sent: Thursday, September 11, 2008 8:35 AM
To: motoroladsp@ yahoogroups. com
Subject: [motoroladsp] Re: DSP fried - Solved with optoisolated programmer
Reply by ●September 15, 20082008-09-15
Carlo,
1) Did you try to unlock flash using Codewarrior? Goto Debug->DSP56800E->Unlock Flash.
2) Do you put 10 ohm resistors between JTAG converter and DSC JTAG pins?
Charlie
--- On Thu, 9/11/08, Carlo wrote:
From: Carlo
Subject: Re: [motoroladsp] Re: DSP fried - Solved with optoisolated programmer
To: m...
Date: Thursday, September 11, 2008, 2:54 PM
adam.barnard_ ch wrote:
> Hi Carlo,
>
> I am using the MC56F8367. When I started using the device, I created
> structures for addressing the hardware registers of the peripherals
> directly. After some playing around with the lincer command file I
> finally got it running on the Freescale DemoBoard. But when I
> downloaded the code to my hardware, I also received the message: Core
> not responding. In my case the problem was that the CodeWarrior
> software automatically initialise ALL variables to zero: In this case
> also ALL the DSP Registers! I could not prevent the software from
> doing it - even after commenting out the ZERO_BSS subroutine. Now I
> am using pointers to structures for addressing the registers and it
> works fine. No "core not responding" messages anymore.
Could you program the DSC after this happened? We had to REPLACE it
(desolder/solder a new one) every time because it wouldn't respond anymore,
even after power cycling and some cooling; and it happened randomly once in a
couple of days or so (we have a stock of a dozen devices).
> So I suggest that you look at the initialising of the clocks and PLL
> etc. Also at the implementation of your reset circuitry.
>
> Another question: Do you have a watchdog enabled? Is your watchdog
> disabled when you try to download new code? A watchdog reset will
> definitely also cause a "Core Not Responding" error.
Watchdog disabled; as far as I know reset circuitry is as found on the data sheet.
Thanks for the reply and best regards,
Carlo.
> --- In motoroladsp@ yahoogroups. com
> , Carlo wrote:
> >
> > Hi,
> >
> > me and my research group are working towards developing a hybrid
> > vehicle, where the electric powertrain is driven by a 56F8323
> Freescale
> > DSC.
> > We frequently have to reprogram the DSC, and once in about ten or
> twenty
> > reprograms the DSC would stop working and give "Core not
> responding" and
> > "Failed to write to FLASH" errors; at this point the only remedy is
> to
> > replace the DSC (DSC fried). Anyone experienced the same problem?
> >
> > I don't know why this happens, we think some weird ground loop but
> how?
> > The vehicle is battery operated and when we program the DSC it sits
> on a
> > bench isolated from ground...
> > Then a colleague brought us an optoisolated programmer like this
> one:
> >
> > http://cgi.ebay. it/ws/eBayISAPI. dll?
>
> ViewItem&item= 320296958416& ssPageName= ADME:L:LCA: IT:1123
> >
> >
> >
> > with this programmer it's been two days without problems! It works
> > great. This confirms the ground loop hypothesis.
> > Freescale used to sell optoisolated programmers but now they don't
> sell
> > them anymore. I think this is the only optoisolated programmer for
> > Freescale DSC on the market. We already contacted the manufacturers
> to
> > buy one.
> >
> > Anyone had similar problems? Any thoughts?
> >
> > Regards,
> > -- Carlo.
> >
1) Did you try to unlock flash using Codewarrior? Goto Debug->DSP56800E->Unlock Flash.
2) Do you put 10 ohm resistors between JTAG converter and DSC JTAG pins?
Charlie
--- On Thu, 9/11/08, Carlo wrote:
From: Carlo
Subject: Re: [motoroladsp] Re: DSP fried - Solved with optoisolated programmer
To: m...
Date: Thursday, September 11, 2008, 2:54 PM
adam.barnard_ ch wrote:
> Hi Carlo,
>
> I am using the MC56F8367. When I started using the device, I created
> structures for addressing the hardware registers of the peripherals
> directly. After some playing around with the lincer command file I
> finally got it running on the Freescale DemoBoard. But when I
> downloaded the code to my hardware, I also received the message: Core
> not responding. In my case the problem was that the CodeWarrior
> software automatically initialise ALL variables to zero: In this case
> also ALL the DSP Registers! I could not prevent the software from
> doing it - even after commenting out the ZERO_BSS subroutine. Now I
> am using pointers to structures for addressing the registers and it
> works fine. No "core not responding" messages anymore.
Could you program the DSC after this happened? We had to REPLACE it
(desolder/solder a new one) every time because it wouldn't respond anymore,
even after power cycling and some cooling; and it happened randomly once in a
couple of days or so (we have a stock of a dozen devices).
> So I suggest that you look at the initialising of the clocks and PLL
> etc. Also at the implementation of your reset circuitry.
>
> Another question: Do you have a watchdog enabled? Is your watchdog
> disabled when you try to download new code? A watchdog reset will
> definitely also cause a "Core Not Responding" error.
Watchdog disabled; as far as I know reset circuitry is as found on the data sheet.
Thanks for the reply and best regards,
Carlo.
> --- In motoroladsp@ yahoogroups. com
> , Carlo wrote:
> >
> > Hi,
> >
> > me and my research group are working towards developing a hybrid
> > vehicle, where the electric powertrain is driven by a 56F8323
> Freescale
> > DSC.
> > We frequently have to reprogram the DSC, and once in about ten or
> twenty
> > reprograms the DSC would stop working and give "Core not
> responding" and
> > "Failed to write to FLASH" errors; at this point the only remedy is
> to
> > replace the DSC (DSC fried). Anyone experienced the same problem?
> >
> > I don't know why this happens, we think some weird ground loop but
> how?
> > The vehicle is battery operated and when we program the DSC it sits
> on a
> > bench isolated from ground...
> > Then a colleague brought us an optoisolated programmer like this
> one:
> >
> > http://cgi.ebay. it/ws/eBayISAPI. dll?
>
> ViewItem&item= 320296958416& ssPageName= ADME:L:LCA: IT:1123
> >
> >
> >
> > with this programmer it's been two days without problems! It works
> > great. This confirms the ground loop hypothesis.
> > Freescale used to sell optoisolated programmers but now they don't
> sell
> > them anymore. I think this is the only optoisolated programmer for
> > Freescale DSC on the market. We already contacted the manufacturers
> to
> > buy one.
> >
> > Anyone had similar problems? Any thoughts?
> >
> > Regards,
> > -- Carlo.
> >
Reply by ●September 15, 20082008-09-15
@Kenneth
"It could get even worse."
As we in Europe have 230V mains, the average voltage at Gnd is not 57 VAC, but 115 VAC.
The problem are not 75 microamps, but the charged Y-capacitor, which is discharged abruptly through that data line which connects first.
This short circuit current can be MUCH higher.
For USB it should be the shield which connects fist, but who knows...
Some energy cold be magnetically transformed (induced) from the shield to data lines.
@Kerry (your answer is very well written!)
"... problem with many (if not all) laptop power supplies."
Not all, there ARE bricks with 3-wire main leads (Of course I have one of this type ;-) ).
As the specs all are quite similar (19VDC, around 4 Amps) , you could try to buy one.
Be sure the laptop-plug is the correct one, there are many different styles.
Another solution would be a small low capacitance "separation transformer" for the laptop.
Another solution is: disconnect mains, touch everything to discharge static voltage, connect C, at last reconnect mains.
But it is not viable because you have to reboot every time.
"1. Don't use a laptop.
2. Or, if you do use a laptop, make a bonding strap from the laptop digital ground (USB ground) to
building ground, and make sure the bonding strap is connected before connecting the programmer. Or,
use a proper three-wire grounding AC cord to connect to the laptop power supply AC two-wire input,
and run the third (grounding) wire in the power cord around the brick to the laptop digital ground."
I insert a small resistor (range 10 - 100 Ohms) in series to reduce/limit the discharge current and ground-loop-problems.
"use a proper three-wire grounding AC cord to connect to the laptop power supply AC two-wire input, and run the third (grounding) wire in the power cord around the brick to the laptop digital ground."
You can solder this ground wire to a plug which you connect to (the shield / Gnd) one of the laptop's free connectors (e.g. Serial line, printer, monitor, USB...).
The same problem occurs also when the PE of the plug of an oszilloscope is taped / disconnected (I know many technicians who do this instead of using a separation transformer) and the gnd-croco touches a circuit unintentionally.
I heard the mains in the Netherlands are 230VAC (as in other european countries), but symmetrically to Ground potential ("+115 and -115 VAC", i.e. 180 offset).
So the middle of the Y-capacitor is at ground (btw. the risc of electrocution is reduced).
In the contrary, we in Germany (and most other countries) have one pole at Ground and the other one at 230VAC.
So, keep everything at ground (-; (mechanicalls spoken: things on the ground cannot fall down).
This topic is "very DSP-related".
Klaus
-----Original Message-----
From: m... [mailto:m...]On Behalf Of Kerry Berland
Sent: Saturday, September 13, 2008 1:34 AM
To: Weber Klaus; 'adam.barnard_ch'; m...
Subject: RE: [motoroladsp] Re: DSP fried - Solved with optoisolated programmer
"It could get even worse."
As we in Europe have 230V mains, the average voltage at Gnd is not 57 VAC, but 115 VAC.
The problem are not 75 microamps, but the charged Y-capacitor, which is discharged abruptly through that data line which connects first.
This short circuit current can be MUCH higher.
For USB it should be the shield which connects fist, but who knows...
Some energy cold be magnetically transformed (induced) from the shield to data lines.
@Kerry (your answer is very well written!)
"... problem with many (if not all) laptop power supplies."
Not all, there ARE bricks with 3-wire main leads (Of course I have one of this type ;-) ).
As the specs all are quite similar (19VDC, around 4 Amps) , you could try to buy one.
Be sure the laptop-plug is the correct one, there are many different styles.
Another solution would be a small low capacitance "separation transformer" for the laptop.
Another solution is: disconnect mains, touch everything to discharge static voltage, connect C, at last reconnect mains.
But it is not viable because you have to reboot every time.
"1. Don't use a laptop.
2. Or, if you do use a laptop, make a bonding strap from the laptop digital ground (USB ground) to
building ground, and make sure the bonding strap is connected before connecting the programmer. Or,
use a proper three-wire grounding AC cord to connect to the laptop power supply AC two-wire input,
and run the third (grounding) wire in the power cord around the brick to the laptop digital ground."
I insert a small resistor (range 10 - 100 Ohms) in series to reduce/limit the discharge current and ground-loop-problems.
"use a proper three-wire grounding AC cord to connect to the laptop power supply AC two-wire input, and run the third (grounding) wire in the power cord around the brick to the laptop digital ground."
You can solder this ground wire to a plug which you connect to (the shield / Gnd) one of the laptop's free connectors (e.g. Serial line, printer, monitor, USB...).
The same problem occurs also when the PE of the plug of an oszilloscope is taped / disconnected (I know many technicians who do this instead of using a separation transformer) and the gnd-croco touches a circuit unintentionally.
I heard the mains in the Netherlands are 230VAC (as in other european countries), but symmetrically to Ground potential ("+115 and -115 VAC", i.e. 180 offset).
So the middle of the Y-capacitor is at ground (btw. the risc of electrocution is reduced).
In the contrary, we in Germany (and most other countries) have one pole at Ground and the other one at 230VAC.
So, keep everything at ground (-; (mechanicalls spoken: things on the ground cannot fall down).
This topic is "very DSP-related".
Klaus
-----Original Message-----
From: m... [mailto:m...]On Behalf Of Kerry Berland
Sent: Saturday, September 13, 2008 1:34 AM
To: Weber Klaus; 'adam.barnard_ch'; m...
Subject: RE: [motoroladsp] Re: DSP fried - Solved with optoisolated programmer
