I2C test

[samtin]

A0, A1, A2 and WP to gnd, SCL to RC3 and SDA to RC4 with pull-up resistors (4.7K)

[mnfisher]

Although it might not be writing the data correctly - it is also possible that Read isn't working (or display!)

Can you upload the chart you are using to test....

[samtin]

Of course, I have attached the flowchart below.

[mnfisher]

One thought - 255 is the value of an 'empty' byte.

Don't have much time today but will try with a PIC and a logic analyser. Other thoughts - is the display i2c as well. (I'm just looking at the code on my phone using the online viewer)

Could you try another 'output' method (flash an Led n times) just in case there is a conflict - but clutching at straws a bit.

I don't have the same pic but a logic analyser is the only way to see what is really going on.

[samtin]

The display is not I2C, only the eeprom.

[mnfisher]

I set up a PIC16LF15313 with a SSD1306 i2c (128 * 64) display. This PIC only has 256 bytes RAM - so I used my minimal ssd1306 component (see viewtopic.php?t=2742&hilit=ssd1306&start=40 ) otherwise no chance....

I also attached a logic analyser - and with i2c set to hardware mode - nothing on SDA and SCL. Changing to software mode and there is life.

Oddly for writing 0 .. 9 I got on the display 0 r 2 t 4 v 6 x 8 z (and I used .x = Read(.i) Print(.x + '0', .i * 10, 2) So- not sure quite what is happening on the odd numbers. I couldn't use PrintNumber - insufficient RAM!

So - try software mode on the i2c. It might just do the trick?

eeprom.jpg (63.89 KiB) Viewed 2462 times

Rather a rats nest - with PICKit and logic analyser attached. The oscilloscope is 'underneath' the breadboard - and there are some bits from my dfplayer tester to the right. Display is also not very bright (it's rather old) - I print some text ("2345") to prove it can display odd numbers - next line is the first 10 bytes read from EEPROM. The PIC is at the left - eeprom in the middle, with the i2c daisy-chained from a1 and a2 (the display and EEPROM have different addresses, so this is okay).

I modified slightly - and printed the address in row 2 and data in row 4 - and row 2 is correct (0 1 2 3...) but the data still has the odd characters (though there is a pattern - they are not random)

Will have another look tomorrow.

Martin

[mnfisher]

It's very odd - looking with the oscilloscope - the write looks correct, as does the read. However whereas for the even addresses it returns the correct data, for the odd addresses it doesn't (for example address 1 returns 0x42)

Very strange. Here is the trace showing the write to address 1, followed by the trace showing read of address 2 then address 1

LabNation_Screenshot34.png (179.08 KiB) Viewed 2412 times

LabNation_Screenshot35.png (187.05 KiB) Viewed 2412 times

Anyone any idea what's going on?

Martin

[mnfisher]

So after a bit of fiddling - I went back to an old version of the 24LC256 component I did a while ago.

Now up and running smoothly in software mode (hardware mode doesn't seem to be supported?)

In a simple demo - it writes 10 bytes (1,2,3 .. 0) to the eeprom then repeatedly reads back the first 5 bytes - shown here on the scope trace.

LabNation_Screenshot36.png (190.46 KiB) Viewed 2264 times

Note that the component works slightly differently to the FC one - the user sets a read and/or write address using StartRead and StartWrite - then they can read or write single or multiple bytes using ReadData and WriteData - and these automatically increment the address to use.

Martin

[samtin]

Hi everyone,
Forgive my absence, I'm back and I also have to thank you very much Martin for your help and for your effort to do good.

[mnfisher]

Welcome back - and hopefully been of some assistance...

Martin