Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #31092 > unrolled thread

Cortex-Mx MCUs with SWD access locked

Back to article view | Back to comp.arch.embedded

Contents

  Cortex-Mx MCUs with SWD access locked pozz <pozzugno@gmail.com> - 2022-06-23 23:38 +0200
    Re: Cortex-Mx MCUs with SWD access locked pozz <pozzugno@gmail.com> - 2022-06-24 11:25 +0200
      Re: Cortex-Mx MCUs with SWD access locked dalai lamah <antonio12358@hotmail.com> - 2022-06-24 12:22 +0200
        Re: Cortex-Mx MCUs with SWD access locked pozz <pozzugno@gmail.com> - 2022-06-24 16:27 +0200
          Re: Cortex-Mx MCUs with SWD access locked dalai lamah <antonio12358@hotmail.com> - 2022-06-24 16:42 +0200
            Re: Cortex-Mx MCUs with SWD access locked pozz <pozzugno@gmail.com> - 2022-06-24 16:56 +0200
              Re: Cortex-Mx MCUs with SWD access locked dalai lamah <antonio12358@hotmail.com> - 2022-06-24 17:16 +0200
            Re: Cortex-Mx MCUs with SWD access locked David Brown <david.brown@hesbynett.no> - 2022-06-24 18:26 +0200
              Re: Cortex-Mx MCUs with SWD access locked Dimiter_Popoff <dp@tgi-sci.com> - 2022-06-24 20:00 +0300
              Re: Cortex-Mx MCUs with SWD access locked pozz <pozzugno@gmail.com> - 2022-06-27 08:54 +0200
                Re: Cortex-Mx MCUs with SWD access locked David Brown <david.brown@hesbynett.no> - 2022-06-27 09:23 +0200
      Re: Cortex-Mx MCUs with SWD access locked David Brown <david.brown@hesbynett.no> - 2022-06-24 14:15 +0200
        Re: Cortex-Mx MCUs with SWD access locked pozz <pozzugno@gmail.com> - 2022-06-24 16:25 +0200
          Re: Cortex-Mx MCUs with SWD access locked Stef <me@this.is.invalid> - 2022-06-24 20:29 +0200
            Re: Cortex-Mx MCUs with SWD access locked David Brown <david.brown@hesbynett.no> - 2022-06-24 20:34 +0200
              Re: Cortex-Mx MCUs with SWD access locked Stef <me@this.is.invalid> - 2022-06-24 22:12 +0200
                Re: Cortex-Mx MCUs with SWD access locked David Brown <david.brown@hesbynett.no> - 2022-06-25 10:19 +0200
            Re: Cortex-Mx MCUs with SWD access locked pozz <pozzugno@gmail.com> - 2022-06-27 09:06 +0200
              Re: Cortex-Mx MCUs with SWD access locked David Brown <david.brown@hesbynett.no> - 2022-06-27 09:25 +0200
          Re: Cortex-Mx MCUs with SWD access locked Reinhardt Behm <rbehm@hushmail.com> - 2022-06-26 14:25 +0000
            Re: Cortex-Mx MCUs with SWD access locked pozz <pozzugno@gmail.com> - 2022-06-27 10:07 +0200
              Re: Cortex-Mx MCUs with SWD access locked Reinhardt Behm <rbehm@hushmail.com> - 2022-06-27 15:11 +0000
                Re: Cortex-Mx MCUs with SWD access locked pozz <pozzugno@gmail.com> - 2022-06-27 23:50 +0200
                  Re: Cortex-Mx MCUs with SWD access locked Stef <me@this.is.invalid> - 2022-06-28 11:23 +0200
                    Re: Cortex-Mx MCUs with SWD access locked pozz <pozzugno@gmail.com> - 2022-06-28 12:42 +0200
                      Re: Cortex-Mx MCUs with SWD access locked Stef <me@this.is.invalid> - 2022-06-28 17:06 +0200

Page 1 of 2  [1] 2  Next page →

#31092 — Cortex-Mx MCUs with SWD access locked

I know it's a very specific question, so I don't have many hopes to find 
a solution here, but I already tried everything and I don't know how to 
solve the issue I have that is very annoying.

I have three PCBs: PCB1 that mounts LPC54101 (M4), PCB2 that mounts 
LPC54606 (M4), PCB3 that mounts LPC54618 (M4). All these MCUs are from NXP.

After I receive the first prototype for each board, I was able to make a 
connection through SWD, by using a J-Link probe. I use MCUXpresso as the 
IDE for debug launch.

Well, after some tests (write some code, download new images, debug some 
and so on), I received an error from the probe: no SWD target found 
(Could not connect to the target).

The MCU appears working well with the last downloaded image, but the SWD 
access seems disabled. Moreover the MCU is able to enter UART ISP Boot 
(by pulling down a specific ISP pin) and I can erase and rewrite the 
internal Flash by UART.
I tried to connect by SWD even when the MCU has booted in ISP Boot ROM, 
without any success.

Ok, something went wrong with this MCU, it could happen on prototypes 
during development.
But the big issue I am worried about and that is incredible for me, is 
that this exactly sequence of events happened for one prototype of PCB1, 
one of PCB2 and one of PCB3!!!

After some program&debug cycle (for a few days all is ok), the probe 
isn't able to connect to the target anymore.

The probe and cables seem ok, because if I replace bricked PCBs with a 
working PCB, all is ok.

I tried to contact NXP support, but they couldn't solve this problem and 
don't know what happened to bricked MCUs.

LPC546xx MCUs have a complex mechanism (some values at specific address 
in the Flash and OTP memory) that allows to restrict access via ISP 
and/or SWD, but LPC5410x is much more simple. The protection is enabled 
by writing some magic words at specific address in the internal Flash. 
However I'm able to erase the internal Flash (by UART ISP) so this can't 
be the reason of SWD issue.
For what I have read, there's now way to lock SWD access after an erase 
of internal Flash memory.

I used J-Link with LPC17xx for many years in the past without any issue. 
What's the problem with LPC54?

Do you have some suggestions?

[toc] | [next] | [standalone]

#31095

Il 23/06/2022 23:38, pozz ha scritto:
> Do you have some suggestions?

Today I found that SWDIO signal isn't able to swing normally between GND 
and VDD on broken MCUs. I suspect something bad occurred inside the MCU, 
but it's strange it happened on three different boards with three 
different MCUs.

Could it be ESD?

[toc] | [prev] | [next] | [standalone]

#31096

Un bel giorno pozz digitò:

>> Do you have some suggestions?
> 
> Today I found that SWDIO signal isn't able to swing normally between GND 
> and VDD on broken MCUs. I suspect something bad occurred inside the MCU, 
> but it's strange it happened on three different boards with three 
> different MCUs.
> 
> Could it be ESD?

Or maybe some ground loops, for example if you have connected the J-Link
probe to a desktop PC (or in general a PC not isolated from mains) and your
boards are somewhat connected to mains or earth ground too.

Note that laptops with the charger plugged in are not perflectly isolated
from mains either. I've experienced noise problems in several occasions
with JTAG probes connected to laptops with the charger plugged in. The
noise disappeared just by unplugging the charger.

-- 
Fletto i muscoli e sono nel vuoto.

[toc] | [prev] | [next] | [standalone]

#31099

Il 24/06/2022 12:22, dalai lamah ha scritto:
> Un bel giorno pozz digitò:
> 
>>> Do you have some suggestions?
>>
>> Today I found that SWDIO signal isn't able to swing normally between GND
>> and VDD on broken MCUs. I suspect something bad occurred inside the MCU,
>> but it's strange it happened on three different boards with three
>> different MCUs.
>>
>> Could it be ESD?
> 
> Or maybe some ground loops, for example if you have connected the J-Link
> probe to a desktop PC (or in general a PC not isolated from mains) and your
> boards are somewhat connected to mains or earth ground too.

Yes, I use a desktop PC connected to mains and the boards are supplied 
from an AC/DC connected to mains too.

Is this a problematic scenario?



> Note that laptops with the charger plugged in are not perflectly isolated
> from mains either. I've experienced noise problems in several occasions
> with JTAG probes connected to laptops with the charger plugged in. The
> noise disappeared just by unplugging the charger.
> 

[toc] | [prev] | [next] | [standalone]

#31100

Un bel giorno pozz digitò:

>> Or maybe some ground loops, for example if you have connected the J-Link
>> probe to a desktop PC (or in general a PC not isolated from mains) and your
>> boards are somewhat connected to mains or earth ground too.
> 
> Yes, I use a desktop PC connected to mains and the boards are supplied 
> from an AC/DC connected to mains too.
> 
> Is this a problematic scenario?

Normally it shouldn't be, but it also depends on what the board does. If it
contains some power stages running at high frequency, it is quite common
(especially if the EMI filtering is subpar) that switching currents can
pass through the AC/DC power supply and create problems.

If this keeps happening, try using a laptop isolated from mains and see if
it helps.

-- 
Fletto i muscoli e sono nel vuoto.

[toc] | [prev] | [next] | [standalone]

#31101

Il 24/06/2022 16:42, dalai lamah ha scritto:
> Un bel giorno pozz digitò:
> 
>>> Or maybe some ground loops, for example if you have connected the J-Link
>>> probe to a desktop PC (or in general a PC not isolated from mains) and your
>>> boards are somewhat connected to mains or earth ground too.
>>
>> Yes, I use a desktop PC connected to mains and the boards are supplied
>> from an AC/DC connected to mains too.
>>
>> Is this a problematic scenario?
> 
> Normally it shouldn't be, but it also depends on what the board does. If it
> contains some power stages running at high frequency, it is quite common
> (especially if the EMI filtering is subpar) that switching currents can
> pass through the AC/DC power supply and create problems.

The target board power input is 12Vdc and on-board DC/DC (TPS54231, 
570kHz) generates a single 3.3V.


> If this keeps happening, try using a laptop isolated from mains and see if
> it helps.

I hate laptop as development machine, I will try some USB and/or 
debugger isolator. However I imaging the problem would arise with 
oscilloscope, UART/USB converter and so on.

[toc] | [prev] | [next] | [standalone]

#31102

Un bel giorno pozz digitò:

>> If this keeps happening, try using a laptop isolated from mains and see if
>> it helps.
> 
> I hate laptop as development machine, I will try some USB and/or 
> debugger isolator. However I imaging the problem would arise with 
> oscilloscope, UART/USB converter and so on.

Maybe, but the peculiarity of the JTAG probe is that it is usually
connected directly to the CPU. Therefore the loop currents may close
directly through the CPU pins, which are quite susceptible to this kind of
things.

This is the reason why sometimes it can be useful to place a buffer (i.e.
74lcx244 or similar) between the probe and the CPU. This may not solve the
problem, but even in the case of a failure you will have to replace just an
inexpensive buffer instead of the entire CPU.

-- 
Fletto i muscoli e sono nel vuoto.

[toc] | [prev] | [next] | [standalone]

#31103

On 24/06/2022 16:42, dalai lamah wrote:
> Un bel giorno pozz digitò:
> 
>>> Or maybe some ground loops, for example if you have connected the J-Link
>>> probe to a desktop PC (or in general a PC not isolated from mains) and your
>>> boards are somewhat connected to mains or earth ground too.
>>
>> Yes, I use a desktop PC connected to mains and the boards are supplied
>> from an AC/DC connected to mains too.
>>
>> Is this a problematic scenario?
> 
> Normally it shouldn't be, but it also depends on what the board does. If it
> contains some power stages running at high frequency, it is quite common
> (especially if the EMI filtering is subpar) that switching currents can
> pass through the AC/DC power supply and create problems.
> 
> If this keeps happening, try using a laptop isolated from mains and see if
> it helps.
> 

Another trick is to make sure you have a separate ground connection 
between the board and the PC before attaching the JTAG.  A wire from the 
board ground to the PC's case is usually fine.

[toc] | [prev] | [next] | [standalone]

#31104

On 6/24/2022 19:26, David Brown wrote:
> On 24/06/2022 16:42, dalai lamah wrote:
>> Un bel giorno pozz digitò:
>>
>>>> Or maybe some ground loops, for example if you have connected the 
>>>> J-Link
>>>> probe to a desktop PC (or in general a PC not isolated from mains) 
>>>> and your
>>>> boards are somewhat connected to mains or earth ground too.
>>>
>>> Yes, I use a desktop PC connected to mains and the boards are supplied
>>> from an AC/DC connected to mains too.
>>>
>>> Is this a problematic scenario?
>>
>> Normally it shouldn't be, but it also depends on what the board does. 
>> If it
>> contains some power stages running at high frequency, it is quite common
>> (especially if the EMI filtering is subpar) that switching currents can
>> pass through the AC/DC power supply and create problems.
>>
>> If this keeps happening, try using a laptop isolated from mains and 
>> see if
>> it helps.
>>
> 
> Another trick is to make sure you have a separate ground connection 
> between the board and the PC before attaching the JTAG.  A wire from the 
> board ground to the PC's case is usually fine.
> 

That might definitely help. I have seen sparks between a DUT and
the scope probe GND more than once.
But most importantly one has to learn to quickly identify when a part
has been blown.
[which is easy to say
of course, I remember some 10-12 years ago how I spent at least 3 days
to figure out why a 5200B was not completing the boot process, after
some disk activity etc.. Turned out I had killed it (tampering with the
1.5V core power regulator, most likely) in a way *one* of its cachelines
had one of its longwords damaged.... I did all the investigation - just
think tracing through the boot process (no debug port, just the CPU)
because I was not very experienced in replacing a BGA.... well, had to
acquire the experience it took, it was stressful but I managed :) ].

[toc] | [prev] | [next] | [standalone]

#31112

Il 24/06/2022 18:26, David Brown ha scritto:
> On 24/06/2022 16:42, dalai lamah wrote:
>> Un bel giorno pozz digitò:
>>
>>>> Or maybe some ground loops, for example if you have connected the 
>>>> J-Link
>>>> probe to a desktop PC (or in general a PC not isolated from mains) 
>>>> and your
>>>> boards are somewhat connected to mains or earth ground too.
>>>
>>> Yes, I use a desktop PC connected to mains and the boards are supplied
>>> from an AC/DC connected to mains too.
>>>
>>> Is this a problematic scenario?
>>
>> Normally it shouldn't be, but it also depends on what the board does. 
>> If it
>> contains some power stages running at high frequency, it is quite common
>> (especially if the EMI filtering is subpar) that switching currents can
>> pass through the AC/DC power supply and create problems.
>>
>> If this keeps happening, try using a laptop isolated from mains and 
>> see if
>> it helps.
>>
> 
> Another trick is to make sure you have a separate ground connection 
> between the board and the PC before attaching the JTAG.  A wire from the 
> board ground to the PC's case is usually fine.
> 

Sorry I don't follow very well these arguments.

You say to have a separate ground connection between the board and the 
PC, but you suggest to connect a wire between them. It seems 
contradictory to me.

What do you mean with board ground? GND, the reference voltage for 3.3V 
of the MCU? Usually I work on boards with only one low-voltage power 
supply input (12Vdc, plus and minus) that is down-scaled to 3.3V by a 
DC/DC switching regulator. There isn't an *earth* connection on the 
board. Mounting holes are connected to GND, but most of the time, the 
board is not mounted on my bench.

[toc] | [prev] | [next] | [standalone]

#31114

On 27/06/2022 08:54, pozz wrote:
> Il 24/06/2022 18:26, David Brown ha scritto:
>> On 24/06/2022 16:42, dalai lamah wrote:
>>> Un bel giorno pozz digitò:
>>>
>>>>> Or maybe some ground loops, for example if you have connected the 
>>>>> J-Link
>>>>> probe to a desktop PC (or in general a PC not isolated from mains) 
>>>>> and your
>>>>> boards are somewhat connected to mains or earth ground too.
>>>>
>>>> Yes, I use a desktop PC connected to mains and the boards are supplied
>>>> from an AC/DC connected to mains too.
>>>>
>>>> Is this a problematic scenario?
>>>
>>> Normally it shouldn't be, but it also depends on what the board does. 
>>> If it
>>> contains some power stages running at high frequency, it is quite common
>>> (especially if the EMI filtering is subpar) that switching currents can
>>> pass through the AC/DC power supply and create problems.
>>>
>>> If this keeps happening, try using a laptop isolated from mains and 
>>> see if
>>> it helps.
>>>
>>
>> Another trick is to make sure you have a separate ground connection 
>> between the board and the PC before attaching the JTAG.  A wire from 
>> the board ground to the PC's case is usually fine.
>>
> 
> Sorry I don't follow very well these arguments.
> 
> You say to have a separate ground connection between the board and the 
> PC, but you suggest to connect a wire between them. It seems 
> contradictory to me.

No, the wire is the connection.

The point is to stop any brief surges passing through the debugger and 
USB system.  When boards get connected or unconnected to supplies and 
other equipment, there can sometimes be slight differences in the ground 
potential.  This can lead to a current pulse, which is sometimes large 
due to capacitances, and this in turn can lead to voltage pulses.  If 
there is a nice, clean path for the current to follow along a direct 
connecting wire, that's where the current will go, and the debugger and 
USB is spared the pulses.

> 
> What do you mean with board ground? GND, the reference voltage for 3.3V 
> of the MCU?

Yes, generally.

> Usually I work on boards with only one low-voltage power 
> supply input (12Vdc, plus and minus) that is down-scaled to 3.3V by a 
> DC/DC switching regulator. There isn't an *earth* connection on the 
> board. Mounting holes are connected to GND, but most of the time, the 
> board is not mounted on my bench.
> 

These mounting holes are often a good point to connect such a ground 
wire - just as the mounting screws on the case of the PC are typically a 
good point on the PC side.

Ideally, the power supply enters a board at one point, and you have a 
star connection from there to any zero volt references (so that noise 
from ground for high power switching does not disturb the 
microcontroller, or high frequency noise on the microcontroller ground 
does not disturb sensitive analogue parts, etc.).  And ideally, this 
ground connection to the PC also comes from that star.  In practice, for 
simpler boards a single ground reference plane is usually all you need, 
and all you need here is for your ground connection wire to have a good 
low impedance connection.  A croc clip wire clipped to the mounting 
holes or screws is fine.

(I am referring to local ground, or zero volt reference - not "true 
ground" or "earth".  You only need an earth connection if you have high 
voltages and safety concerns.)

[toc] | [prev] | [next] | [standalone]

#31097

On 24/06/2022 11:25, pozz wrote:
> Il 23/06/2022 23:38, pozz ha scritto:
>> Do you have some suggestions?
> 
> Today I found that SWDIO signal isn't able to swing normally between GND 
> and VDD on broken MCUs. I suspect something bad occurred inside the MCU, 
> but it's strange it happened on three different boards with three 
> different MCUs.
> 
> Could it be ESD?

I don't know these particular microcontrollers in detail, but there are 
two things that can cause problems with debugging that I can think of.

One is that you can often re-use the pin as a GPIO.  If your program 
re-uses the debug pins as GPIO, then maybe this is happening before the 
debugger can get access.  The debugger should be able to fix this if it 
has access to a hard reset pin, but some setups are missing that.

The other is that sometimes you can disable the debugger for security 
reasons.  I've done that by accident on a microcontroller (an AVR, IIRC).


Of course you could always have had damage from ground loops, spikes 
when plugging the debugger in and out (if power is on), short-circuits 
when trying to use an oscilloscope probe with clumsy fingers, etc.  If 
you have access to an X-Ray machine, you might be able to get some idea 
about what happened.

[toc] | [prev] | [next] | [standalone]

#31098

Il 24/06/2022 14:15, David Brown ha scritto:
> On 24/06/2022 11:25, pozz wrote:
>> Il 23/06/2022 23:38, pozz ha scritto:
>>> Do you have some suggestions?
>>
>> Today I found that SWDIO signal isn't able to swing normally between 
>> GND and VDD on broken MCUs. I suspect something bad occurred inside 
>> the MCU, but it's strange it happened on three different boards with 
>> three different MCUs.
>>
>> Could it be ESD?
> 
> I don't know these particular microcontrollers in detail, but there are 
> two things that can cause problems with debugging that I can think of.
> 
> One is that you can often re-use the pin as a GPIO.  If your program 
> re-uses the debug pins as GPIO, then maybe this is happening before the 
> debugger can get access.  The debugger should be able to fix this if it 
> has access to a hard reset pin, but some setups are missing that.

Yes I know that, but these microcontrollers can be booted into ISP UART 
mode by pulling down a pin at power up. When the MCU is in ISP mode, 
your application doesn't started so the pins stay configured as per 
their default, so SWD pins are SWD configured.

In my case, these MCUs enter ISP mode normally (I can send ISP commands 
and receive replies), but even in this state the debugger can't connect 
via SWD.


> The other is that sometimes you can disable the debugger for security 
> reasons.  I've done that by accident on a microcontroller (an AVR, IIRC).

Yes I know that too. LPC546XX MCUs are complex on this topic, but 
LPC541XX MCUs are very simple. You can restrict SWD access by writing 
magic values on certain positions.
However I can erase the entire Flash through ISP commands, so after 
erasing all restrictions should be disabled.


> Of course you could always have had damage from ground loops, spikes 
> when plugging the debugger in and out (if power is on), short-circuits 
> when trying to use an oscilloscope probe with clumsy fingers, etc.  If 
> you have access to an X-Ray machine, you might be able to get some idea 
> about what happened.

I admit I don't have professional workbench with anti-static writ strap 
band and so on, but I worked for many years without these kind of 
problems. It's strange I encountered so many problems concentrated in a 
few weeks.

I will understand the problem of ground loops.

[toc] | [prev] | [next] | [standalone]

#31105

On 2022-06-24 pozz wrote in comp.arch.embedded:
> Il 24/06/2022 14:15, David Brown ha scritto:
>
>> Of course you could always have had damage from ground loops, spikes 
>> when plugging the debugger in and out (if power is on), short-circuits 
>> when trying to use an oscilloscope probe with clumsy fingers, etc.  If 
>> you have access to an X-Ray machine, you might be able to get some idea 
>> about what happened.
>
> I admit I don't have professional workbench with anti-static writ strap 
> band and so on, but I worked for many years without these kind of 
> problems. It's strange I encountered so many problems concentrated in a 
> few weeks.
>
> I will understand the problem of ground loops.

Anti-static measures will not help for any of the problems David
describes. But they will prevent damage from ESD. Which could also be a
source for your problem.

Has the weather been very dry in those problem weeks? Or did you change
your floor or did you get new shoes? 


-- 
Stef

Eureka!
		-- Archimedes

[toc] | [prev] | [next] | [standalone]

#31106

On 24/06/2022 20:29, Stef wrote:
> On 2022-06-24 pozz wrote in comp.arch.embedded:
>> Il 24/06/2022 14:15, David Brown ha scritto:
>>
>>> Of course you could always have had damage from ground loops, spikes
>>> when plugging the debugger in and out (if power is on), short-circuits
>>> when trying to use an oscilloscope probe with clumsy fingers, etc.  If
>>> you have access to an X-Ray machine, you might be able to get some idea
>>> about what happened.
>>
>> I admit I don't have professional workbench with anti-static writ strap
>> band and so on, but I worked for many years without these kind of
>> problems. It's strange I encountered so many problems concentrated in a
>> few weeks.
>>
>> I will understand the problem of ground loops.
> 
> Anti-static measures will not help for any of the problems David
> describes. But they will prevent damage from ESD. Which could also be a
> source for your problem.
> 
> Has the weather been very dry in those problem weeks? Or did you change
> your floor or did you get new shoes?
> 
> 

My experience with ESD damage is that it is often subtle - it leads to 
long-term reliability issues, rather than outright failures.  So the 
production department at my company is extremely careful about ESD.  Up 
in the development department, we can be a bit laxer as long as the 
devices are not going to customers (or at least, not going further than 
the customers' development departments).  I can't remember ever having a 
failure that I could definitely attribute to ESD damage in my lab, while 
I have definitely solved reliability problems by extra ground connections.

Mind you, I would still avoid woollen slippers on a nylon carpet!

[toc] | [prev] | [next] | [standalone]

#31107

On 2022-06-24 David Brown wrote in comp.arch.embedded:
>> 
>
> My experience with ESD damage is that it is often subtle - it leads to 
> long-term reliability issues, rather than outright failures.  So the 

True, only large discharges will have an immediate effect. And you will
probably have felt the spark. 

> production department at my company is extremely careful about ESD.  Up 

Same here. Conductive floors and no access in certain areas without
conductive shoes or conductive straps in normal shoes.

> in the development department, we can be a bit laxer as long as the 
> devices are not going to customers (or at least, not going further than 
> the customers' development departments).

Also very recognizable. ;-)
We do have ESD matts on most work tables, but wrist straps are seldomly
worn. Floors on development are not conductive, but not static as well.
Have never felt a discharge on touching stuff there.

> I can't remember ever having a 
> failure that I could definitely attribute to ESD damage in my lab, while 
> I have definitely solved reliability problems by extra ground connections.

I think I had such an incident in my home office before I changed the
floor. With certain footware on the old floor I'd spark all over the
place in dry conditions. Irritating and not good for the equipment.

> Mind you, I would still avoid woollen slippers on a nylon carpet!

Laminate flooring and some plastic shoe soles are also a no-no.


-- 
Stef

stop bit received

[toc] | [prev] | [next] | [standalone]

#31108

On 24/06/2022 22:12, Stef wrote:
> On 2022-06-24 David Brown wrote in comp.arch.embedded:
>>>
>>
>> My experience with ESD damage is that it is often subtle - it leads to
>> long-term reliability issues, rather than outright failures.  So the
> 
> True, only large discharges will have an immediate effect. And you will
> probably have felt the spark.
> 
>> production department at my company is extremely careful about ESD.  Up
> 
> Same here. Conductive floors and no access in certain areas without
> conductive shoes or conductive straps in normal shoes.
> 
>> in the development department, we can be a bit laxer as long as the
>> devices are not going to customers (or at least, not going further than
>> the customers' development departments).
> 
> Also very recognizable. ;-)
> We do have ESD matts on most work tables, but wrist straps are seldomly
> worn. Floors on development are not conductive, but not static as well.
> Have never felt a discharge on touching stuff there.
> 
>> I can't remember ever having a
>> failure that I could definitely attribute to ESD damage in my lab, while
>> I have definitely solved reliability problems by extra ground connections.
> 
> I think I had such an incident in my home office before I changed the
> floor. With certain footware on the old floor I'd spark all over the
> place in dry conditions. Irritating and not good for the equipment.
> 
>> Mind you, I would still avoid woollen slippers on a nylon carpet!
> 
> Laminate flooring and some plastic shoe soles are also a no-no.
> 

I solve that by never wearing shoes inside.

Technically, I fail the conductivity tests everyone has to take before 
entering the ESD areas, but it's a "too good" failure.  That means I am 
fine to handle boards, but I'm not allowed to play with any high voltage 
testbenches - the conductive path through me to ground is too good!

[toc] | [prev] | [next] | [standalone]

#31113

Il 24/06/2022 20:29, Stef ha scritto:
> On 2022-06-24 pozz wrote in comp.arch.embedded:
>> Il 24/06/2022 14:15, David Brown ha scritto:
>>
>>> Of course you could always have had damage from ground loops, spikes
>>> when plugging the debugger in and out (if power is on), short-circuits
>>> when trying to use an oscilloscope probe with clumsy fingers, etc.  If
>>> you have access to an X-Ray machine, you might be able to get some idea
>>> about what happened.
>>
>> I admit I don't have professional workbench with anti-static writ strap
>> band and so on, but I worked for many years without these kind of
>> problems. It's strange I encountered so many problems concentrated in a
>> few weeks.
>>
>> I will understand the problem of ground loops.
> 
> Anti-static measures will not help for any of the problems David
> describes. But they will prevent damage from ESD. Which could also be a
> source for your problem.
> 
> Has the weather been very dry in those problem weeks? Or did you change
> your floor or did you get new shoes?

Very dry? On the contrary, now and here we have humid air at least 
respect other periods of the year.

No change in floor or shoes.

[toc] | [prev] | [next] | [standalone]

#31115

On 27/06/2022 09:06, pozz wrote:
> Il 24/06/2022 20:29, Stef ha scritto:
>> On 2022-06-24 pozz wrote in comp.arch.embedded:
>>> Il 24/06/2022 14:15, David Brown ha scritto:
>>>
>>>> Of course you could always have had damage from ground loops, spikes
>>>> when plugging the debugger in and out (if power is on), short-circuits
>>>> when trying to use an oscilloscope probe with clumsy fingers, etc.  If
>>>> you have access to an X-Ray machine, you might be able to get some idea
>>>> about what happened.
>>>
>>> I admit I don't have professional workbench with anti-static writ strap
>>> band and so on, but I worked for many years without these kind of
>>> problems. It's strange I encountered so many problems concentrated in a
>>> few weeks.
>>>
>>> I will understand the problem of ground loops.
>>
>> Anti-static measures will not help for any of the problems David
>> describes. But they will prevent damage from ESD. Which could also be a
>> source for your problem.
>>
>> Has the weather been very dry in those problem weeks? Or did you change
>> your floor or did you get new shoes?
> 
> Very dry? On the contrary, now and here we have humid air at least 
> respect other periods of the year.
> 

Humid is good.  In electronics production facilities, air humidifiers 
are common as humid air lets any static buildups drain away safely.  (Of 
course, there is always a limit - you don't want condensation on your 
boards!)

> No change in floor or shoes.
> 

[toc] | [prev] | [next] | [standalone]

#31110

On Fri, 24 Jun 2022 16:25:55 +0200, pozz wrote:


>> Of course you could always have had damage from ground loops, spikes
>> when plugging the debugger in and out (if power is on), short-circuits
>> when trying to use an oscilloscope probe with clumsy fingers, etc.  If
>> you have access to an X-Ray machine, you might be able to get some idea
>> about what happened.
> 
> I admit I don't have professional workbench with anti-static writ strap
> band and so on, but I worked for many years without these kind of
> problems. It's strange I encountered so many problems concentrated in a
> few weeks.
> 
> I will understand the problem of ground loops.

Take the exact setup and before plugging the debugger measure the voltage 
between the CPU board ground and the debugger ground with a multi meter 
in AC mode. My guess is that you have stray AC (mains) voltage on either 
side (by Y-caps in a PSU or just capacitive coupling over the transformer 
to the DC side GND). These stray voltages often reach 50% of AC voltage, 
in you case probably 60V-AC. When you plug the connector they might 
easily kill a CPU port.


-- 
Reinhardt

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web