Mod a standard eep programmer to incircuit programmer?

[Chriss]

Hi!
I'm not sure if this is the right section of the forum to post my question, but maybe yes.
If not, please delete or move it to a more specific section.
Thank you.

So, here is what I thought to do:
I have a simple eeprom programmer, let's say an average programmer what is doing the job for me well.
I would like to implement a "hack" or "mod" however to have an ability to r/w my eep's in-circuit.

I'm not sure does these are the only think what made me problem:
- overcurrent protection in the programmer
- a possibility to wake up the oscillator on the board where the attacked eep is
- ?

Some old days (years ago) I can remember we shorted out the oscillator on the board to prevent the uC wakeup and
interrupt the r/w process of the eep.
I don't know if that is nowadays a good idea.

I think so:
If I would short out the oscillator on the attacked board, the uC would be blocked to wake up.
If I would power the eep through his power pins through a bench power supply that should
feed enough current to the whole system attached and so I could override the overcurrent protection in my programmer.

The programmer should actually be setup in parallel with all that connection in a proper way and maybe would work.

So, what you think about my thinking?

Thanks for any advice.
My best regards.

[Chriss]

I would like to rehab this post, does anybody of you have something to add/correct me If I would do this in a real situation,
what could go wrong ?

What is the down side of my thinking compared to a cheap in-circuit programmer lets say for some sort of 93xx or 95xxx eep's?

Or maybe somebody can advice me with some simple schematic for in-circuit r/w simple eep's?
So I can better understand how that "in-circuit" stuff is working...

Thank you.

[coromonadalix]

Some notes

http://www.giantec-semi.com/Upload/AN001_MW_en.pdf
https://www.kanda.com/blog/programming/copying-serial-eeproms/


Normally the programmer will try to read it thru the spi mode or like in the notes with an clip adapter who snap on top of you ic.

If the board design permit it:    meaning it can override the (sk cs din dout lines), it should be read and be re programmable

Choose an already built programmer, dont try to fiddle and modify one, there is timing issues and many other things who can go wrong.

[NorthGuy]

If I need to program EEPROM in-circuit, I just program it through the MCU which already has all the connections to EEPROM anyway. May be there are situations where you would need to program EEPROM in-circuit independently of MCU, but I haven't seen them.

[coromonadalix]

It depends on how the eeprom data lines are,  if they are pulled high or low, and if its a strong pull  Ie: resistors values or a short.

My elnec programmer does that, (with an smt clip and dupont jumpers) i can choose the drive current up to 350ma in its special 20 pins idc port, only one board i had could not be programmed, had to remove an smt resistor and re-programmed fine, and put back the smt

[PCB.Wiz]

..
Some old days (years ago) I can remember we shorted out the oscillator on the board to prevent the uC wakeup and
interrupt the r/w process of the eep.
I don't know if that is nowadays a good idea.

I think so:
If I would short out the oscillator on the attacked board, the uC would be blocked to wake up.
If I would power the eep through his power pins through a bench power supply that should
feed enough current to the whole system attached and so I could override the overcurrent protection in my programmer.

Why not hold the uC in reset ?
These days, most MCUs have a reset pin, but not all uC have external oscillator pins anymore...
If the uC is in reset, then the pins are usually ok to drive externally. (floating, or light pull-ups)

[Chriss]

Yea! That's also a good idea to hold the uC stady. I forgot to say that, I we also used that method too.
Thanks for the nice idea.

I'm not familiar how these "in-circuit" eep programmers are built actually.

I know the risk of in-circuit r/w where everything can go wrong, the fw. in the uC could be corrupted also the eep content too.

I never tried a non-in-circuit programmer to use the way we talk here.

Actually this concept should work lets say for a 24c32wp or some 93Cxx or 95xxx eep:

- block the uC by reset pin or oscillator
- connect programmer to the pins on eep as they would be connected in the programmer out of the circuit
- preferred is to power the eep through an external power supply cos the modern eep programmer have current limiting systems integrated.
If the programmer can not delivery enough current to the whole board where the attacked  eep is then the programmer will shut down and no r/w is possible.

Is this a good walkthrough how to achieve the goal?

Sent from my SM-J500F using Tapatalk

[Zantan]

Hi, Just wanted to know as to whether you were successful. I am also interested with in circuit programming especially relating to automotive chips relating to ecu and srs.

[Chriss]

Hi!
No.
I was playing with non-incircuit programmer to mod them to r/w incircuit but I didn't succeeded.


Sent from my SM-J500F using Tapatalk

[Zantan]

I r/w mostly 95xxx chips within auto airbag module relating to crash data deletion and resetting. Currently I desolder, do the r/w and resolder. This is getting quite tiresome as 95 chips in this modules are about 5 mm by 7 mm, 8 pin chips so you can imagine how careful I have to be as well as it being a bit of a painstacking task! I think it would be so much easier if I could prog incircuit. Planning to buy some cheapo airbag module units form scrap merchants and doing some experiments of my own. Any experience in this area either yourself or other forum members?

[KL27x]

So what's the major problem? I assume it is keeping the MCU on hold while flashing the EEPROM?

Your issue will depend on the MCU and how you can do that. As well as how you are going to get a physical connection to an EEPROM chip on a board that isn't designd for it?

There are chip clips for SOIC-8 that clips right over the chip and make all 8 connections. I have never seen one for SSOP/TSOP/SO-8, though.
 
I think Chriss OP lays it out pretty well.

Also, there's hopefully just one EEPROM on the bus, not multiple with different addresses. I think you'd be kinda screwed in that case.

[Zantan]

I also think Chriss was on the right track and that is why I enquired as to whether he was successful.

I am using CH341A and I have also on order TL866 being shipped to me. You may know this that CH341A is pretty simple and basic as you can get and though it gives me upto 5v, it will most likely be susceptible to "influences" when connected to eeprom in circuit.

As to Soic 8 clip adapter I already have one as I am planning to use this (see image). They are quite handy and can read desoldered chips quite well.

Airbag unit containing eeprom will of course be off car and off power.

As to the major problem you are correct but not only MCU as other components may well draw on the voltage as airbag unit will be off power.

As I mentioned prev I am planning to get some old airbag units from a yard. Once I get this I will open it up and submit some images for you to digest and analyse. 

[Zantan]

Sorry just noticed I also uploaded 95320 datasheet by mistake. Well have fun reading it  as now I am sure it may come in useful for our discussions, so will not remove it.

[Zantan]

Here is the 95320 chip as was original intention to upload

[Chriss]

Hi!
As I mentioned before in one of my post, I didn't succeed to r/w any of the mentioned eep with the method I posted before.
Why?
I have no clue.
Here is how I stacked the eep:
Used eep r/w tool: TL886
- jump wired the mcu reset pin so the mcu can not start. ( soldered a wire )
- found test points on the pcb which are direct connected to the eep and soldered wires what I after connected to the TL886 socket
- powered the eep through external 5V psu
- started the TL886 program and tried to read the eep but only FF was read out.
- tried to write but nothing was written,
even if the program told "successful written"
After this I desoldered the  eep and checked if it is maybe not bad but it was fine.
So, based on this experience I don't know why I couldn't succeed the task.
That should work, but...
What I suspect is that some of the secure pin of the eep was maybe pulled in a way does it can't be r/w. I'm not sure about this but I don't have  another explanations.

NOTE!
Stay away from that cheap China soic clips. That is just junk...

Sent from my SM-J500F using Tapatalk

[Zantan]

"Stay away from that cheap China soic clips. That is just junk..."  yes, bit of a lottery, actually a lot of a lottery! Having said that Chinese press down Zif's are the worst.

For only FF being read out, well FF is the default read for my CH341A when it is not properly connecting with the chip. In fact it reads FF's without a chip as well. From this starting point writing part logically could not be possible anyway.

Yes I also agree it should have worked and I also think you are on right track. Maybe some very minor issue that is still persistent. From FF's I am tempted to say connections but I am sure you have checked this countless times. By the way my CH341A can read the data from in circuit eeprom from unpowered airbag unit without any other modifications but it is just not consistent. Cannot attempt write though as cannot afford to mess up working airbag unit so I have to get scrappy units to experiment properly.

By the way are you r/w airbag chips as well? If so I have seen a you tube video whereby a guy only shorts a crystal and can r/w as this apparently completely disables everything to the eeprom. I will have to trawl through youtube to find it again and maybe post a link.