Searching \ for '[PIC]: 16C57 vs 16C57C, a weird problem' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=16C
Search entire site for: '16C57 vs 16C57C, a weird problem'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: 16C57 vs 16C57C, a weird problem'
2003\02\04@163415 by Scott Touchton

picon face
I have a design that utilizes a C57C that reads an eeprom (93LC46A)  on power up.  Everything works correctly, it is very simple bit bang communication.

When employing a plain old C57, the processor does not get its operating data from the eeprom correctly.  When watching the DO pin of the eeprom, it passes the correct data to the C57 properly sync'd with the clock pulses.   However the processor is not reading it correctly (based upon viewing improper operation).  I am only passing on 5 addresses, so I could easily watch the entire communication and view the correct data clocking out of the eeprom.

Here is the weird part:  When I reset the processor, it reads the eeprom and gets the data correct!

Power supply comes up in less than 40us (0 to 5V), and we wait 500ms before accessing eeprom.  I did try holding the processor in reset for several seconds (thinking the eeprom needed more time for some reason to stabilize) but this also did not work.  First read is wrong (3 addresses appear to be read OK, last 2 are wrong).  Resetting the processor again causes it to read the proper data.  I do have a voltage detector handling processor reset.

What is really odd is that I can view the datastream heading to the processor, so I know the eeprom was initialized correctly and has clocked out correct data for the 5 addresses.  The processor simply clocks this data into registers and uses them to set up power level,  carrier frequencies and modulations.  3 addresses are interpreted correctly, 2 are not.  Put the same code into a C57C and it works the way the code says it should.  So... I figure I am missing something in migration.


I have reviewed all the migration notes between the C57 and C57C (all pretty simple), and have never run into an issue like this before.

All eeprom communication is text book and well within timing requirements (no need for speed).

Any help appreciated, especially stupid items I have overlooked in migration.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body

2003\02\04@181717 by Spehro Pefhany

picon face
At 04:28 PM 2/4/2003 -0500, you wrote:
{Quote hidden}

Do you hold /CS high for the 500ms before attempting to access the EEPROM?

Are the clock and data pins in the same state at the point where /CS goes
low?

Are you sure there is no issue with the ORG input on some 93xx46's -
these parts vary SIGNIFICANTLY from manufacturer to manufacturer.

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
.....speffKILLspamspam@spam@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body

2003\02\04@190548 by Scott Touchton

picon face
I am holding the CS pin low until the end of the 500ms delay.

Clock is strobed with CS and DI pin at a logic 0
CS and DI are then taken high, then the clock is strobed again to set the
start bit.
After that, DI is toggled as required to send the opcode while the clock is
strobed.

Should I hold CS high during the 500ms delay?  I thought the 93LC46A toggled
on the positive going edge... do I have that backwards??  Figured i would
keep everything low until ready for use, clock in one cycle with CS and DI
low, then clock in one cycle with CS and DI high to send start bit.

The ORG should be OK... the 46A has no ORG, it is always 8 bit.

{Quote hidden}

reward"
> .....speffKILLspamspam.....interlog.com             Info for manufacturers:
http://www.trexon.com
> Embedded software/hardware/analog  Info for designers:
http://www.speff.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

2003\02\04@203806 by Spehro Pefhany

picon face
At 07:02 PM 2/4/2003 -0500, you wrote:
>I am holding the CS pin low until the end of the 500ms delay.
>
>Clock is strobed with CS and DI pin at a logic 0
>CS and DI are then taken high, then the clock is strobed again to set the
>start bit.
>After that, DI is toggled as required to send the opcode while the clock is
>strobed.
>
>Should I hold CS high during the 500ms delay?

No, sorry, I mixed this up with the 25xx series devices I've been using
lately.
CS should be held low. It may not be an issue, but I always make sure there
are no internal pullups enabled and add an external pull-down resistor in
cases like this.

>  I thought the 93LC46A toggled
>on the positive going edge... do I have that backwards??  Figured i would
>keep everything low until ready for use, clock in one cycle with CS and DI
>low, then clock in one cycle with CS and DI high to send start bit.

Yes. +ve edge on CLK is for data in/out. You're meeting the timing
requirements?
Note a rather slow 400nsec between CLK +ve edge and valid data at the output.

>The ORG should be OK... the 46A has no ORG, it is always 8 bit.

Microchip's is like that, anyhow. I think Fairchild and ST's 46A's *do* have
the ORG pin.

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
speffspamspam_OUTinterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body

2003\02\05@075530 by Olin Lathrop

face picon face
> >I am holding the CS pin low until the end of the 500ms delay.
> >
> >Clock is strobed with CS and DI pin at a logic 0
> >CS and DI are then taken high, then the clock is strobed again to set
the
> >start bit.
> >After that, DI is toggled as required to send the opcode while the
clock is
> >strobed.
> >
> >Should I hold CS high during the 500ms delay?
>
> No, sorry, I mixed this up with the 25xx series devices I've been using
> lately.
> CS should be held low. It may not be an issue, but I always make sure
there
> are no internal pullups enabled and add an external pull-down resistor
in
> cases like this.

Isn't all this EEPROM stuff a red herring?  He said that he could see the
data coming out of the EEPROM just fine.  That means the problem lies
elsewhere.

I would look for things like uninitialized variable bugs.  This could
explain why it works the second time.  Since the powerup state of RAM is
undefined, different chip variants or lots or even individual chips could
easily exhibit different symptoms.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
KILLspampiclist-unsubscribe-requestKILLspamspammitvma.mit.edu>

More... (looser matching)
- Last day of these posts
- In 2003 , 2004 only
- Today
- New search...