89C51ED2
in [Design]
|
From: TT_Man on 4 Sep 2008 08:58 > > How does the defect manifest itself ? > > 8051s have been 'rock solid' IME. As someone else memtioned, do you have a > critical timing issue anywhere ? Like an I/F chip maybe ? Are PSEN, ALE, > /WR > and /RD all clean ? You're probably not using PSEN but never hurts to > check. > > No-one's messed about with the clock oscillator parts have they ? > > What do the 10 lines of code do ? > > Graham > > An extra speech phrase is output.... ALE PSEN /wr/rd are all unused as the device is a 64K flash part. We have several generations of board that all support various chip types, 52, 53 ED2 etc. The faulty ED2's will not execute correctly in any board. The 10 lines of code basically index a speech phrase and output it 3 times to a dac. Then the routine checks an input and proceeds or not via a branch. somewhere in these lines of code, another speech phrase is output. Speech is terminated via a null byte. The extra speech phrase in not contiguous with the correct phrases, so it's not going to be a DPHL corruption...that somehow skips the null byte detection.
From: MooseFET on 4 Sep 2008 09:07 On Sep 4, 8:58 pm, "TT_Man" <Some...(a)ntlworld.com> wrote: > > How does the defect manifest itself ? > > > 8051s have been 'rock solid' IME. As someone else memtioned, do you have a > > critical timing issue anywhere ? Like an I/F chip maybe ? Are PSEN, ALE, > > /WR > > and /RD all clean ? You're probably not using PSEN but never hurts to > > check. > > > No-one's messed about with the clock oscillator parts have they ? > > > What do the 10 lines of code do ? > > > Graham > > An extra speech phrase is output.... ALE PSEN /wr/rd are all unused as the > device is a 64K flash part. We have several generations of board that all > support various chip types, 52, 53 ED2 etc. The faulty ED2's will not > execute correctly in any board. > The 10 lines of code basically index a speech phrase and output it 3 times > to a dac. Then the routine checks an input and proceeds or not via a branch. > somewhere in these lines of code, another speech phrase is output. Speech is > terminated via a null byte. The extra speech phrase in not contiguous with > the correct phrases, so it's not going to be a DPHL corruption...that > somehow skips the null byte detection. Does the code have interrupts enabled? Is it written in ASM or C? What does the code do right as it comes out of reset? Would it perhaps play this phrase? What is the clock speed and what does the VCC look like?
From: Eeyore on 4 Sep 2008 09:29 MooseFET wrote: > "TT_Man" <Some...(a)ntlworld.com> wrote: > > > How does the defect manifest itself ? > > > > > 8051s have been 'rock solid' IME. As someone else memtioned, do you have a > > > critical timing issue anywhere ? Like an I/F chip maybe ? Are PSEN, ALE, > > > /WR > > > and /RD all clean ? You're probably not using PSEN but never hurts to > > > check. > > > > > No-one's messed about with the clock oscillator parts have they ? > > > > > What do the 10 lines of code do ? > > > > > Graham > > > > An extra speech phrase is output.... ALE PSEN /wr/rd are all unused as the > > device is a 64K flash part. We have several generations of board that all > > support various chip types, 52, 53 ED2 etc. The faulty ED2's will not > > execute correctly in any board. > > The 10 lines of code basically index a speech phrase and output it 3 times > > to a dac. Then the routine checks an input and proceeds or not via a branch. > > somewhere in these lines of code, another speech phrase is output. Speech is > > terminated via a null byte. The extra speech phrase in not contiguous with > > the correct phrases, so it's not going to be a DPHL corruption...that > > somehow skips the null byte detection. > > Does the code have interrupts enabled? > > Is it written in ASM or C? I think he said it was all written in asssembler <yuk>. Graham
From: Joerg on 4 Sep 2008 10:43 Eeyore wrote: > > Joerg wrote: > >> TT_Man wrote: >>> Anyone using this part experiencing problems? we have used them for 4 years >>> or so. Date codes up to 0705 work ok, 0814 misbehaves....same chip, same >>> software, 0814 doesn't execute properly... >> Did you check the POR situation? Maybe issue a nice long POR and see if >> it'll run? >> >> The POR circuit on most 8051 is %^&#!! <tantrum censored> so I always >> rolled my own. As for BOR, I think many uC designers don't know what >> that means ... > > I think Atmel actually do an app note on that. > When it comes to POR/BOR I do not trust manufacturers much. Learned some hard lesson in life. -- Regards, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.
From: Rich Grise on 4 Sep 2008 17:46
On Wed, 03 Sep 2008 16:14:23 -0700, Joerg wrote: > TT_Man wrote: >> ">> Is this an Atmel part? >>>> If so, I would check the datasheets for updates. >>>> I know on their 8252/3 series, they made a change to the crystal cap >>>> requirements. >>>> Went from 30pf to around 5pf. Would occasionally cause improper >>>> startup/reset, and very slow operation if it did reset. If they >>>> changed the oscillator on ED2, that could very well be the problem. >>>> (?) >>>> >>> Hopefully not without changing the rev level and informing their >>> customers? Yikes, I sure hope not. >> >> Joerg, I get regular updates on all atmel processor revision changes/data >> sheet spec changes, . In this respect, Atmel are 100% on the ball. >> AFAIK there have been none for this particular part...... > > That's good. I'd call them anyhow though. I once had an issue with them > regarding an 89C51 that was advertized at a higher clock than it could > do. IIRC it was touted as 16MHz but I could only get it to run at 12MHz. > They did apologize and other than that it ran in that same design > forever. In fact, it's still in production, over a decade now. That's > the beauty of 8051 designs, those things are like the VW Beetle. If I could get an 8051 equivalent but with Motorola's timer system (see 68HC11, e.g.), I'd be in hog heaven. ;-) Cheers! Rich |