Booting Eval-1701 board from external EEPROM?

Hi Freddie,

I got your message. Sorry about the long wait. I've been going full steam on a very urgent PCB design that I just finished up yesterday, and while that project was underway I unfortunately didn't have much time to spend on forum and support issues.

First, let me ask a few questions:

How did you generate the EEPROM image file?

How did you download the image to the board?

Is the SELFBOOT pin held high?

What is the I2C address of the EEPROM?

Have you tried self-booting just on power-up, or have you also tried keeping power supplies enabled and then toggling the reset line?

No problem, thanks for getting back to me!!

1) The EEPROM file was generated in the method I described in a post https://ez.analog.com/message/24488#24488 My EEPROM burner requires the file to be in Intex format, so I had to convert.

2) I used the MPLab Starter Kit (from Microchip) to burn the EEPROM. I then place the chip into a socket on my board.

3) In my schematic I have SELFBOOT tied high. But looking at my PCB layout, it's possible that pin is just floating. If so, that would be the problem, correct?

4) The I2C address of the EEPROM, when I set it up in SigmaStudio was 0xA0.

5) I don't have the ability in my PCB design to toggle the RESET line, and I'm realizing this is something I should have at least jumpered for testing, right? I wonder if my RC network I'm using on the RESET line isn't working right.

I'm going to check the SELFBOOT line first, then try to cut the RESET line so I can manually reset the board at will...

Thanks!

--> freddie

CORRECTION: SELFBOOT is tied high.

OK, so the EEPROM generation method looks good. I can't confirm on my side that the intel hex format conversion was successful or not. However, we should be seeing some sort of I2C activity if the selfboot mechanism is activating.

SELFBOOT must be tied high... it looks like you've been able to confirm that.

Have you checked that the actual address pins of the EEPROM on your board match the 0xA0 address? For typical EEPROM ICs, this means that A0, A1, and A2 are all tied to GND.

Let me know if the reset attempt works. I'm thinking that there might be something weird going on with power supply sequencing... If you do the selfboot-on-reset test then it will eliminate that as a potential root cause.

I'm not totally sure what you mean when you say: "Have you checked that the actual address pins of the EEPROM on your board match the 0xA0 address? For typical EEPROM ICs, this means that A0, A1, and A2 are all tied to GND."

A0, A1, and A2 on my EEPROM are tied to ground, yes. But I'm not sure what you mean by the address pins matching the 0xA0 address...

--> freddie

Freddie, I just realized that I have access to your schematic. Everything looks good to me.

One thought I had was that the I2C pull-ups might be to strong. That's probably unlikely, but it's a possibility. You might want to try raising them.

Here's another weird thought. It's possible that with WP enabled on the EEPROM, something is inhibiting the self-boot. On the 24LC256 datasheet, it says:

2.4 Write-Protect (WP)
This pin must be connected to either VSS or VCC. If tied
to VSS, write operations are enabled. If tied to VCC,
write operations are inhibited but read operations are
not affected.

So, read operations should work. But, that's something worth testing. Maybe you could pull WP low and see if it changes anything.

I'm still stuck, doesn't seem to boot. Is there no way to boot my Eval board off my DIP8 EEPROM? That would at least eliminate the EEPROM programming as the issue.

When I measure the volages on the EEPROM pins, I am seeing something weird...the voltages are not all 3.3V (a couple pins are showing like 2.74V), but I don't see that on the Eval board. Does that raise any kind of flag? The pull-up resistors on those pins are all 2k though (measured).

Thanks!

--> freddie

Is there anyone here to help me?? I'm stuck and at this point cannot get my circuit to boot. Is there any service available for getting custom help, like have someone look at the board? I feel like in 15 minutes, one of your engineers could figure this out very easily since they know the chip.

Thanks!

--> freddie

Hi Freddie,

We can continue debugging via direct email. When we solve this problem we can post the solution here for the rest of the community.

This question has been assumed as answered either offline via email or with a multi-part answer. This question has now been closed out. If you have an inquiry related to this topic please post a new question in the applicable product forum.

Thank you,
EZ Admin