TLC59208F Programming - MODE1 Register Low Power Mode

David,

Is this issue happening directly from startup? Have you tried directly addressing one of the devices that are not working (not using auto-increment or all call)?

We can try to break this down addressing a specific device and specific registers to determine if the device is set to the correct SW state first.

Harry,

Thanks for looking at this -

Yes, I have a hard reset button on my board which resets the 3 208F chips I have on the board.

Then I tried to directly address one of them , just by reading the registers and I see 157 in the 18th byte.
Note that I see 3 in the first byte which seems to indicate mode2, then I have 8 zero's which indicate each of the pwm.
So, it seems to me that mode 0 is coming in byte 18 and not byte 0.

But I cannot reset this byte. I am able to set other bytes such as pwm and led.

Note that I am using the microsoft Spot hardware library to do I2C communication.

David, can you fill this out for me

[Device0], [Address], [working/not working],
...
[DeviceX], [Address]. [Working/not working].

next I'll be asking the status of the mode 0 bit, and LED status bit.

I'm more interested in mode0, but by doing a straight call to that specific register (address read -> 0). Your response is giving me the impression that you're still using the auto-increment. This is fine, but for debugging, let's only address single registers in order to isolate the root of the problem.

Ok Harry,

[Device0],[46], [not working]
[Device0],[47], [not working]
[Device0],[80],[Working]
[Device1],[81],[Working]
[Device1],[82],[Working]
[Device1],[83],[Working]

Thanks David,

are the addresses in hex or decimal. Also does this include the R/W bit in it?

for address 46 47 and 80, can you please read back address 00h (Mode 1), and 0Dh (LEDOUT0)?


I'm going to work on the auto-increment implementation while I keep probing in this thread.

Harry,

Yes, you are correct that I was using the auto-increment, it seemed like the only way I could read the registers when I started developing this.

The addresses are in decimal.
Note that address 46 or 0x2E as a 7bit addr if shifted 1 bit to the left corresponds with the address 0x5C as given on page 17.
(NOTE that table 1 shows a 7bit slave addr which is then shifted and converted to hex, for example, the first entry gives the
7bit slave addr 10000 = 16 = 0x10 is shown as addr 0x20 assuming it is shifted.
(It is the 11th grouping of 3 addresses which is known to me as LED 11 as we use 3 addresses to create 1 LED).

Using the Microsoft.SPOT.Hardware library, I create an I2CDevice configuration and then set up and I2CTransaction.

Once I set up an address (tlc59208fDevice = new I2CDevice(46); for example.......

I don't know if I'm individually setting (w/o auto-incr) this up to read correctly.
For example, using I2Device, I do this in order to attempt to read mode1 (00h):

xActions[0] = I2CDevice.CreateWriteTransaction(new byte[] { 0x00, 0x5D}; // addr 46 shifted becomes 0x5C, then set R/W bit = 1 to = 0x5D
xActions[1] = I2CDevice.CreateReadTransaction(RawData); //just a buffer
retVal = tlc59208fDevice.Execute(xActions, 500); // this executes the transaction and does the i2c behind the scenes, 500ms t/o.

When I do this for 0x00 (mode1) I get:
addr 46 = 29
addr 47 = 31
addr 80 = 1


for 0x0D (LED0) I get:
addr 46 = 93
addr 47 = 95
addr 80 = 161

(none of those make sense to me.......)
note that 93 = 0x5D which is just the value I had sent {0x0D, 0x5D} just 0x0D + shifted addr + r/w
similiarly for addr 80, 161 = 0xA1 which was the sent val {0x0D, 0xA1}

seems like I am not able to just read, I guess I'm doing something wrong.
But as mentioned, if I read all registers {0x80, 0xA1} for example, I get back 18 bytes that seem to make sense for certain addresses......

Hi Harry,

I reread through the Microsoft I2C stuff and it seems that if I just send the register (1 byte), it knows to set the R/W bit.
So, I reran my program and this time only send 1 byte
xActions[0] = I2CDevice.CreateWriteTransaction(new byte[] { 0x00}; //
xActions[1] = I2CDevice.CreateReadTransaction(RawData); //just a buffer
I think maybe this is reading now as I first tried with 0x01 and got a 0x03 which seems to make sense (mode 2 = 3 by default).
When I do this, I get the same values for each address:

0x00 (mode 1)
addr 46, 47 and 80 all = 17 (0x11)
0x0D (led0)
addr 46, 47 and 80 all = 0 (0x00)

David

David,

Sorry for the delay, but I'm glad that the individual addressing helped. For me I don't use Microsoft to control my I2C, but you've confirmed that the individual registers are functional. If you run into any other questions, feel free to let me know.