EEPROM Load Failure

SRLM · 2012-12-19 12:33

Hi everyone,

The Problem
I can't get the EEPROM to load, either from BSTC or PropGCC Propeller-load. In both cases I get EEPROM load errors, both with no more information that "failed".

Background
On my I2C bus I have 6 devices: the AT24C512C EEPROM, a gyro, a magnetometer/accelerometer combo, a fuel chip, and a barometer. I have a program that I use to "ping" the devices, and each device reports back with the I2C ACK signal. I can also get good data from all the other devices (from the program when it's just loaded into RAM).

I'm confident that the EEPROM is hooked up correctly, since I have an identical board that is not populated with any I2C device except the EEPROM, and I'm able to load that.

I've captured the traces of the I2C communication on for both BSTC and Propeller-Load, and attached them as a screenshot. As you can see they both fail in similar ways.

Miscelenous info
1. This is the EEPROM that I'm using: http://www.atmel.com/Images/doc8720.pdf
2. Both SDA and SCL lines are pulled up with 1.6KOhm resistors. I selected this value based on the measured bus capacitance, and viewing the oscilloscope traces to make sure the edges were square. In any case, this problem still exists with 10KOhm resistors instead.
3. This same problem is manifested across 4 identical boards.
4. The same code will load EEPROM on a similar layout on the PPDB
5. The Propeller-load terminal output:

>>$ propeller-load -r -v -S -e -t230400 filename.tabs.binary
Propeller Version 1 on /dev/ttyUSB0    
Ignored 88 bytes. 
Loading filename.tabs.binary to EEPROM via hub memory
9880 bytes sent                  
Verifying RAM ... OK
Programming EEPROM ... failed
error: load failed

6. The code is Spin code, compiled with BSTC (and with a generated .binary file).
7. Edit: Here are the other devices on the I2C bus. All are rated for 400kHz I2C:
http://www.meas-spec.com/downloads/MS5611-01BA03.pdf (ok, this one says I2C and SPI up to 20MHz, so I assume 400kHz is safe)
http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/DM00036465.pdf
http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/DM00027543.pdf
http://datasheets.maximintegrated.com/en/ds/MAX17048-MAX17049.pdf

Question
What can I do to fix this, or at least what can I test to figure out what is wrong?

Dave Hein · 2012-12-19 12:42

Have you tried disconnecting the other devices on the I2C bus? Maybe one of them is stepping on the bus, possibly because it can't run at 400 KHz.

SRLM · 2012-12-19 13:51

Dave Hein wrote: »

Have you tried disconnecting the other devices on the I2C bus? Maybe one of them is stepping on the bus, possibly because it can't run at 400 KHz.

Unfortunately, disconnecting other devices is a pain because it's all SMD. With my I2C driver I can successfully run the devices at 400KHz (loaded from RAM, and measured with my logic analyzer), and it's producing correct data. I have an identical board that has all the I2C devices removed except the LSM303DLHC and the EEPROM, and that one loads.

As a side note, I measured the EEPROM load sequence as going at 285 kHz.

Dave Hein · 2012-12-19 14:17

Even though the EEPROM load sequence is running at 285 kHz it's possble that some timing parameter, such as clock or data setup or hold is being violated for one of the other devices. Chip posted the loader code a while ago, and you could try running some tests with his EEPROM driver to see if there's a problem in a stand-alone test. There is a link to the loader, runner and Spin interpreter posted in the Wiki somewhere.

RossH · 2012-12-19 18:09

Hi SLRM,

If you want to see if your program will load at 100Khz, catalina's payload loader can load standard Spin binaries into EEPROM at either 100Khz or 400Khz. By default, it uses 100Khz.

If your Prop has a 5Mhz clock, download Catalina, open a Catalina Command Line window and build the utilities for the CUSTOM platform (invoke the build_utilities command, enter CUSTOM as your platform and N to all the other questions).

Then try loading your binary using the command:

payload EEPROM my.binary

Ross.

jazzed · 2012-12-19 21:49

Programming the EEPROM with propeller-load is done with the Propeller ROM program. Verification of EEPROM programming is done by the Propeller ROM and it is go or no-go.

What package revision is your propeller-load from? Long ago EEPROM programming was broken because the protocol was misunderstood. I haven't seen any failures in almost a year. One of my boards has 5 I2C devices and 4.7K pull-ups and is fine. Are the 1.6KOhm resistors too strong? 10K may be too much with 6 devices.

All of your devices are DFN or equivalent? Can you stuff the EEPROM only board one part at a time to identify the "apparent" cause?

Is the MS5611-01BA03 pin 2 pulled up for I2C mode?

Just curious. Are you using the Quickstart FTDI circuit?

LoopyByteloose · 2012-12-20 06:16

Can you load an image to RAM and properly boot? While this seems to be entirely an EEPROM issue with a loaded bus, you might discover something else.

Loading a binary directly with a utility might be another useful approach. I believe that Brad's Spin Tool has a command line loader.

It could be that the acknowledge processes for 6 devices are creating some unexpected traffic that Parallax hasn't provided a code solution for.

Dave Hein · 2012-12-20 06:27

Here's the link to the Prop ROM code. The I2C driver is in booter.spin.
http://forums.parallax.com/showthread.php?101483-Propeller-ROM-source-code-HERE

T Chap · 2012-12-20 07:02

How about load to ram a test code that attenpts to write and read a single byte off the eeprom.

You do not have a rework station to lift the other devices one at a time? A sharp pencil will let you het under the V+ to each chip, lift the pin on each chip one at a time and test loading to eeprom.

Have you tried a different computer?

LoopyByteloose · 2012-12-20 07:40

From reading your original posting and looking at the images, you may just have too many devices on one bus and you are having collision problems caused by small differences in timing or by components sourced from different manufacturers.

6 devices on one bus is challenging at best. And I cannot see if you tested as you added additional items one at a time or if you tested all them individually and then just put everything together.

The value of your pullup is also very strong. And the position of the pullup may be causing part of the problem.

If all the devices will work on one bus, it may be best to remove them from the EEPROM bus and use two other pins. I know this isn't the solution that you are hoping for, but it may be a good backup if you can't find a way to make this work. Board traces can be cut and rewired if one has to.

Another alternative is to disconnect the other devices while programing the EEPROM and reconnect after the EEPROM is loaded.

EEPROM Load Failure

Comments