Some how I have a feeling that the read bit is not going high during a read
So the read address is not correct
What specific device do you have - where’s it’s datasheet? And how do you have the A0-A2 address lines wired, if your device has them? I see you’re using 0x50 which doesn’t look wrong based on a0-a2 all being 0’s in the address bits.
it is a EEPROm
24L16
–
Right now my problem is
I write to Address ( basically I am writing a u32)
0 => 0
1 => 0
2 => 0
3 => 6
And I read back Address 0 and I get back 6.
The fact that you get a 6 to me shows the write isn’t working correctly.
going back to first principles…
Write a 0 to address 0
Write a 1 to address 1
Write a 2… you know how it goes.
Stop when you think you should (16? 32? 100?)
Read back address 0, display results.
Read back address 1, display results.
What do you get?
ok…found the issue.
EEPROM 24C16 and lower devices only used 1 byte for address. The Address MSB goes in the A0, A1, A2 control bits.
I am now using 24LC64 EEPROM.
And I am using the latest releases. ( 4.1.6.0)
I get ASSERTS when writing to EEPROM sometimes. It does not happen when runnign with debugger. Only with jsut teraterm it happens
!!!ASSERT!!!
But I never get it with an older version I have on 4.0
I2C code was never changes as far as I know!
Please provide small test project to repro this behavior.
Gus
It is not happening on a stand alone test code.
As I was telling this is not happening in the debugging enviroment too.
it is some timing issue.
Since I see the
!!!ASSERT!!!
There is something wrong.
If you can give me some test code with more I2C debug messages enabled.
I can run it and get you the logs
ASSERT should never happen and if it did then something went terribly wrong! In order for us to fix, we would need to know hot to reproduce.
Before you proceed with anything, I suggest that you erase all flash and deploy the tinybooter and the firmware again. I am afraid that at some point you update the firmware without updating the tinybooter ( I am talking EMX and ChipworkX of course)
Joe,
I erased every thing and still the same when lot of writes happen to the EEPROM on I2C
!!!ASSERT!!! happens on 4.1.6.0
But then I tried with 4.1.5.0. And it does not happen.
So at least I have a working version on 4.1 which is much later than 4.0 which I had working before.
All this I am trying on EMX
This would be near impossible for us/you to catch if we do not have some sort of test or at least exact details on how it happened.
Like, is it related to having multiple devices? thread? clock?..etc.
Microt, perhaps you can just create a vigorous read/write test app that stresses the I2C bus and your devices?
Hello I need some help with the same exact EEPROM as OP. Also am using the same driver. I get an argument exception when doing EEPROM.Write(address,data);
I am not sure what the address part should look like (for initalizing I2C I use 0x50 since I have A0,A1,A2 shorted to ground), is the write address the same 7 bit address or would it be like 0,1,2 etc? I tried EEPROM.Write(1,bytes[1]) to see if that would change anything but I still got the error.
the I2C address in netmf is only ever the “read” address. Without looking at the driver, EEPROM.Write(1,something) is likely writing to logical location 1 in the EEPROM, and will not use the I2C address.
Plus, there’s several different chips talked about here, and there’s no complete driver, I’d suggest you start up a single new thread with all the info needed for your situation and don’t confuse it with anyone else’s.
EDIT: I see you’d already started the separate thread, great !!