Some thoughts on the "61 loop" issue

[knagl]

A friend of mine who occasionally lurks here sent me the following message which provides some very interesting insight into what may cause the "61 loop" issue after a dead battery error:

I have dealt with this a lot, this "61 loop" thing I believe happens when the jackpot reset key has been operated while there is a "12" battery bad code displayed.  For some reason, it locks something up. 

I always can clear this by putting a different number SP chip in and reseting the machine with it installed, then I can return to the original SP and it works. Otherwise, I've been told a clear chip works also, although I've not tried this.

I don't think I would have ever tried turning the jackpot reset key on the one occasion I had a dead battery (and I never encountered the "61 loop" issue, either), but on the other hand I'm sure a lot of the n00bs do exactly that because they know from experience that the jackpot reset key tends to reset some errors (just not a battery issue, of course).  When they do that, apparently they're unknowingly setting themselves up for failure when they replace the battery.

To that end, if you have a error 12 when you power up your IGT S+ slot machine, do NOT turn the reset key.  Turn the machine off, replace the battery, and you should be back in business.

[jay]

Good thoughts !

[stayouttadabunker]

Good thoughts knagl!
It would be easy to replicate though....just pull the lead off the battery, power up the machine and turn the Reset key?
I'll try it first thing Monday morning to see if that's what causes the [61] loop...

[stayouttadabunker]

Well...uh....it's been a few Mondays! 
I was reminded about this particular topic/problem so I tackled it.

I'm using a 2CM Double Diamond Deluxe machine that had 52 credits on the display before
I un-soldered one end of the MPU onboard battery leads - forcing a [12] (Dead Battery) error.

I tried to determine by turning the Reset/Jackpot key, whether or not this "mis-step" forces the machine
to go into a [61] error "loop".

As a result, all I get when I turn the Reset key, is go into the accounting/bookkeeping" mode.
Also, when the MPU booted up, I only received the [65-1] message which means "Bad EEPROM Data" -
which is resolved by simply pressing the Test button once and closing the door...

Apparently, turning the Reset key while a error [12] ("bad battery") is NOT the reason
for the [61] error "loop" we've been seeing....as the chip on the motherboard seems
to retain all my settings and accounting records.

Sooo...what really causes the [61] error "Loop"?   

Here's a video clip I made for you guys this morning....>>>


<a href="http://www.youtube.com/v/5ipMOyHprSw&rel=0" target="_blank">http://www.youtube.com/v/5ipMOyHprSw&rel=0</a>

[CUDA3134]

I resolved my 61 loop by reseating the CMOS and wiring the cash box door switch together. I think in your experiment you would need to wait some time for the retained information to be lost. At least an hour. I had a jackpot lockup on a Franco machine that I cleared by removing the Dallas Battery but had to wait for the information to drain off before I was successful.

[CVslots]

Bunker, you just amaze me...anyway, while drinking coffee and talking to my husband while reading your post on your findings, it reminded him of an issue hes had in the past that got us thinking. And as a disclaimer, ive only had one cup, so my brain is not at full spped yet!!!!  

We've had games that when the new chips were installed and the game was fired up, the machine still plays the old game for 5-7 spins, then up pops the 61. Didnt think much of it at the time, just cleared the 61 as usual and went on....but NOW, it makes me wonder if this somehow is relative to the 61 loop.  

Lets think about what happens (or what is supposed to happen) to the CMOS when a game change occurs? The issue that we had suggests that the CMOS was late to the party for some reason, perhaps a buffer of some sort, or maybe it just didnt get the message instantly that the game had changed. When it got the message, it caught up and did its job as normal. Could this somehow be linked to the loop? Seems to be relative, as ive heard guys pulling the CMOS chip for a couple minutes to do a quick "partial clear".

-Roslyn

[stayouttadabunker]

Roz,
Poppo has done some extensive testing with both the motherboard chip and the MPU's CMOS chips.
I think he would have a better answer for you than I.
I'm more of a tinkerer that has the capabilities to mess around with machines a little bit
because I have quite a few parts and tools to play with.

For the time being, I cannot seem to "force" a [61] "Loop" to occur on purpose
and it's a fairly common problem that a lot of owners seem to run into.
I don't know what causes that problem.
The only thing I can possibly think of is a "stuck" logic signal.

So far, the only way that I know of to get past it is to drop in a Clear chip and
then re-install the SP chip to get the computer to "see" the Reset key logic signal ( with the door closed)
to go towards [61-1].

As far as I know, the Clear chip's function restores the MPU's CMOS & motherboard's chip back to factory settings
by magnetizing or applying a small charge to all of the chip's logic gates to a "zero" value?
Someone feel free to correct me on this assumption...thanks!
Grounding out the legs of the MPU's CMOS chip only "screws" it up on purpose which forces the MPU to a different error?
It effectively erases the credits from the chip though.

[poppo]

I think in your experiment you would need to wait some time for the retained information to be lost. At least an hour.

Ok, here is my $.02 for what it is worth.

First let's talk about the error 12. Each time the machine is powered up, the CPU (program) looks at the battery voltage. It does not read the actual voltage though. There is an on-amp that is used to determine if the battery has dropped below a certain threshold. If it has, the op-amp output changes state and the CPU now knows the battery is low. It then writes that error to the CMOS and/or the EEPROM and displays it. I do believe it gets written to the EEPROM too, and Bunkers video tends to support that (the 65_1 error after he replaced the battery).

To address the above quote, removing the battery will immediately cause the CMOS to lose it's memory, so I do not believe letting it sit for any length of time will make any difference. There is no residual voltage to keep the CMOS memory intact for more than a fraction of a second. All of the 5V circuitry on the board would have drained any residual capacitor charge very quickly. However, I am very puzzled as to why Bunker only got a 65_1 and not a 61. And why he still had credits. Loss of CMOS data should have cleared the credits since that data is not normally stored on the EEPROM. Perhaps an error 12 does write credit data to the EEPROM so that the information is not lost from a dead battery.

Now, what causes a 61 loop? I'm not sure. However, from doing various steps to try and clear it without using a clear chip (or forcing an EEPROM write by changing the game chip), the only conclusion I can come to is that the EEPROM has either become corrupt, or for some reason has a "hard error" written to it that requires the use of a clear chip (or game swap). I'm 99.999% certain that the 61 loop is caused by what is stored in the EEPROM (bad or intentional data). Just not sure what the bad data is or how it got there. Maybe powering it up multiple times with a 12 still on it. One of these days when I have some time, I'll try a bunch of different scenarios since my S+ MPUs all have removable batteries.

[stayouttadabunker]

Great post Poppo 
I like hearing your thoughts.

An idea crossed my mind....  I always come up with different ideas but don't know how to apply them too too well...
here it is...>>> wouldn't it be kind of cool to see "live-time" CMOS data as it's being written to a chip during events
and projected onto a laptop screen?
It's too bad we don't know what the goobleygook data stuff is though... 
IGT engineers of course, had to encrypt it... 

[poppo]

here it is...>>> wouldn't it be kind of cool to see "live-time" CMOS data as it's being written to a chip during events
and projected onto a laptop screen?

Actually that might not be "too" difficult. I can think of a few ways to read the data, but knowing what each is would be the tricky part. I don't think it;s encrypted since I am reading the data off of the EEPROM in my LCD project. It would take a lot of comparing the data before/after an event to see what has changed. For example, dropping in a coin will increment the credits, so one can just look and see what has changed before and after the coin was dropped. But besides for the credits incrementing, the coin in counter has too. It would take a lot of trial and error.

[bznhvx]

Cmos chips will hold data for some time, not reliably, but you cannot assume all (or any) of the data will corrupt instantly.

[poppo]

Cmos chips will hold data for some time, not reliably, but you cannot assume all (or any) of the data will corrupt instantly.

The only CMOS chips I've ever seen that can retain their memory is those that have a build in backup battery. Any other will lose any data within milliseconds of loss of power. So it's pretty safe to assume that the data will be corrupt/lost instantly on loss of power/battery backup.  A low battery might result in partially corrupt data, but once it falls below a threshold kiss the data goodbye. If you can provide a link showing otherwise (for CMOS like those used in these slots) please do so.