I know your business well. I designed an early player card system for 
Deadwood.

- - -

In several designs, I experienced problems with the PIC16Fxxx EEPROM's. No,
the -A version is just as bad. So much so that I try NOT to use them. 
But, if I have
to...

what works is to write an algorithm that writes the variable in 3 places 
in EEPROM,
then when one of them has a dropped bit (best 2 of 3) when the variable 
is read out,
I rewrite all 3. It increases a 20 word routine to about 50 words, but 
it works well.

On the other hand, if you can store the variables in program space, you 
only need
to do it once. THAT flash array always works fine.

--Bob

William Killian wrote:

>I've inherited a board developed by an outside contractor that uses a
>PIC16F874.  I've lots of time on other processors but this is the first
>I've really dealt with a PIC up close and personally.
>
> 
>
>We make slot machines and this board is the reel controller.  Almost all
>the time it happily runs along take commands from what amounts to a PC
>running DOS that is the main computer in the machine.  One of the
>functions that the reel controller has is sending the reels (stepper
>motors with 200 steps but 22 stops or symbols on the reel strips) to a
>known safe losing position if there is a game failure.  A goof early on
>before I was at the company was that the reel strips were designed with
>no thought to where a bad hardware failure would tend to send them.  So
>on one game family ( and yeah our most popular) if all reels go to motor
>step 0 the top prize is displayed on the reels.
>
> 
>
>To get around that the PC sends a command to the PIC to change the home
>or fault positions to some known safe point with a different stop on
>each reel.  The values are stored in the internal EEPROM.  Again almost
>all the time - well over 99.99% of the time this is all cool.
>
> 
>
>BUT some times the game is happily chugging along and the reel
>controller apparently loses its mind.  It decides there was a failure
>and the reels get sent to home positions (the going home action is a
>slower spin so we know it is a sent home problem not a bad decision
>about where to send them) but for some reason the reels all go to step 0
>with is 4 steps off of the stop for top prize.  Not good for a slot
>machine to fail and display what looks like a big win.  Not good to the
>tune of some half a million in payouts a year.
>
> 
>
>Okay amusing story done, does anyone know under what conditions a PIC
>might have trouble reading the internal EEPROM?  Design decisions in
>making the board were some I would not have made and the programming
>style is not one I would have used but I see no failure mode in the code
>that would lead to this.
>
> 
>
>The original contractor told me that a colleague told him that there was
>a known problem with the PIC16F87x and EEPROM that was fixed in the
>PIC16F87xA but I've not seen that anywhere else so far.  Anyone else
>know something like that?  White wiring an RC network to the board to
>let us use the A part (a change to MCLR/Vpp) is fine but changing
>thousands of board on the chance it might fix something is a tad
>expensive.  If it saves a half mill a year it is a great investment
>though.
>
> 
>
>Any PICophile knowledge that could help me here?
>
> 
>
>Bill Killian
>
> 
>
>
>
>-------------------------------------  Notice of Confidentiality ----------------------------------------------------------
>This email and any files transmitted with it are confidential and intended solely for the use of the 
>individual or entity to whom they are addressed. If you have received this email in error please notify 
>postmaster@vgt.net. This message contains confidential information and is intended only for the 
>individual named. If you are not the named addressee you should not disseminate, distribute or 
>copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by 
>mistake and delete this e-mail from your system. If you are not the intended recipient you are notified 
>that disclosing, copying, distributing or taking any action in reliance on the contents of this information 
>is strictly prohibited.
>  
>


-- 
Note: To protect our network,
attachments must be sent to
attach@engineer.cotse.net .
1-520-850-1673 USA/Canada
http://beam.to/azengineer

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist