Post by thread:Confirm IRP bug in 16C77?

PicListers, Sorry to drag this one up again, but I don't think it was ever properly settled. It has come back to haunt me. There was debate over whether strange things happen when INDF is used to access RAM banks 2 & 3 in the 16C76/77. It was suggested that it was necessary to always set/clear RP1 together with IRP in order for INDF accesses to work correctly. However it would fail only when certain (unrelated) operations involving the STATUS register occurred. This is not IMHO how it should work, and I can find no reference to a bug in Mchip documentation. My own experience is that this is true for my emulator (RICE16) but probably not for the "real" part. Of course this is still bad news! Does anyone know the truth of the matter? -- Alan Hall, Ipswich, UK

>There was debate over whether strange things happen when INDF is used to >access RAM banks 2 & 3 in the 16C76/77. It was suggested that it was >necessary to always set/clear RP1 together with IRP in order for INDF >accesses to work correctly. However it would fail only when certain >(unrelated) operations involving the STATUS register occurred. > >This is not IMHO how it should work, and I can find no reference to a >bug in Mchip documentation. > >My own experience is that this is true for my emulator (RICE16) but >probably not for the "real" part. Of course this is still bad news! > >Does anyone know the truth of the matter? We are shipping a product which controls IRP separately from INDF in a '76. It works fine in our product. Andy ================================================================== Andy Kunz Life is what we do to prepare for Eternity ------------------------------------------------------------------ spam_OUTandyTakeThisOuTrc-hydros.com http://www.rc-hydros.com - Race Boats .....andyKILLspam@spam@montanadesign.com http://www.montanadesign.com - Electronics ==================================================================

In article <4.1.19990811163601.009b99c0KILLspampop.fast.net>, Andy Kunz <.....supportKILLspam.....MONTANADESIGN.COM> writes > >We are shipping a product which controls IRP separately from INDF in a '76. > >It works fine in our product. Andy, Thanks for that. Do you use an emulator of any sort? I am coming around to thinking it must be a bug in the bondout, or possibly my emulator, although I can't see how the emulator could influence things when it's running at full speed. I have arranged my source to conditionally build with or without the code to match IRP and RP1 depending on the target. The real silicon SEEMS to be fine without the extra code. -- Alan Hall, Ipswich, UK

On Thu, 12 Aug 1999 09:31:26 +0100, you wrote: >In article <EraseME4.1.19990811163601.009b99c0spam_OUTTakeThisOuTpop.fast.net>, Andy Kunz ><supportspam_OUTMONTANADESIGN.COM> writes >> >>We are shipping a product which controls IRP separately from INDF in a '76. >> >>It works fine in our product. > >Andy, > >Thanks for that. Do you use an emulator of any sort? I am coming around >to thinking it must be a bug in the bondout, or possibly my emulator, >although I can't see how the emulator could influence things when it's >running at full speed. > >I have arranged my source to conditionally build with or without the >code to match IRP and RP1 depending on the target. The real silicon >SEEMS to be fine without the extra code. Not directly relevant but I know of at least one other case where the bondout chip used in a picmaster probe behaves differently to the 'real' silicon, so it's not unheard of.

>Thanks for that. Do you use an emulator of any sort? I am coming around >to thinking it must be a bug in the bondout, or possibly my emulator, >although I can't see how the emulator could influence things when it's >running at full speed. Well, since the bondout uses the same die... We use the Tech Tools Mathias emulator. Andy ================================================================== Andy Kunz Life is what we do to prepare for Eternity ------------------------------------------------------------------ @spam@andyKILLspamrc-hydros.com http://www.rc-hydros.com - Race Boats KILLspamandyKILLspammontanadesign.com http://www.montanadesign.com - Electronics ==================================================================

In article <RemoveME37b29b9e.402375TakeThisOuTsmtp.netcomuk.co.uk>, Mike Harrison <spamBeGonewwlspamBeGoneNETCOMUK.CO.UK> writes >Not directly relevant but I know of at least one other case where the >bondout chip used in a picmaster probe behaves differently to the >'real' silicon, so it's not unheard of. Mike, out of interest, can you recall the details? -- Alan Hall, Ipswich, UK

On Thu, 12 Aug 1999 15:31:01 +0100, you wrote: >In article <TakeThisOuT37b29b9e.402375EraseMEspam_OUTsmtp.netcomuk.co.uk>, Mike Harrison ><RemoveMEwwlTakeThisOuTNETCOMUK.CO.UK> writes > >>Not directly relevant but I know of at least one other case where the >>bondout chip used in a picmaster probe behaves differently to the >>'real' silicon, so it's not unheard of. > >Mike, out of interest, can you recall the details? Yes - when sending synchronous data (can't remember if it was the SSP or SPI) in master mode, instead of a nice regular group of 8 clock pulses, 'gaps' appear in the clock pulse train on the emulator, but not on the real device. The pattern of gaps depended on something - can't remember if it was the data pattern or something more obscure. You still get the right number of clock pulses, and the data comes out at the right time, so you won't notice this unless speed is critical, or you're doing what I was trying - using the sync data output to generate pulse patterns.

In article <4.1.19990812100611.009a6100EraseME.....pop.fast.net>, Andy Kunz <EraseMEsupportMONTANADESIGN.COM> writes >>Thanks for that. Do you use an emulator of any sort? I am coming around >>to thinking it must be a bug in the bondout, or possibly my emulator, >>although I can't see how the emulator could influence things when it's >>running at full speed. > >Well, since the bondout uses the same die... > >We use the Tech Tools Mathias emulator. Andy, I don't know much about the emulation side of things, but it has been explained to me by my supplier as follows; My emulator contains a 16C02-ME/L (the "bondout") and a 16C77-ME. The code actually runs in the 16C02. I guess you are correct in saying that comes from the same die as the 16C77, but it has parts of the die, which were never intended to see the outside world, brought out to pins. That alone may cause subtle differences in operation. (Apparently it also makes the bondouts especially sensitive to static in handling). The 16C77 in the emulator is also "special" - a normal one won't work here. It provided the interface to the real world, presumably using the special connections into the 16C02. But the main point was that the world demand for bondouts is not very high, so the first batch tends to last a long time! Thus they tend to be rather old silicon, with all the finest bugs known to man. Well I don't know if all that is true, but it has been suggested that replacing my 16C02 with the later 16C03 will fix my problem (and let me emulate at 20MHz). I'll let you know. Do you know which part/date code is in your Tech Tools? Regards, -- Alan Hall, Ipswich, UK