This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
I am using Arduino to read address 0x09 (DATA1)
Without performing any writes, first 4 bytes are reading back as [64, 0 , 0, 0]. Should this not be all zeros?
The first byte returned is always 64. Even after i write [107, 28, 1] I am still reading back [64, 28, 1, 0].
Please help. My code definitely talks to the IC and writes at least the 2nd/3rd bytes. My code definitely reads register 0x09 but why is the first byte always 64?
I am using ardunio uno, the following code:
Wire.beginTransmission(0x21); //start the communication with IC
Wire.write(0x09);
Wire.endTransmission(true);
//request 4 bytes from device
Wire.requestFrom(0x21, 4);
if (Wire.available()) {
for(int i=0; i<4; i++) {
dataArrayRead[i] = Wire.read();
Serial.print("4CC: ");
Serial.print(dataArrayRead[i]);
Serial.println();
}
}
Hi Kiran,
Hope you keeping well.
You code is reading register 0x09.
The first byte read, will signify the number of data bytes you will receive. In your case, you are reading register 0x09, from the datasheet we notice the number of data bytes for the register is 64 (0x40). Hence your first byte is 0x40.
I have attached reads from few registers for your reference:
1) 0x30 - RX_SOURCE_CAPS:
write to 0x20 ack data: 0x30
read to 0x20 ack data: 0x1D 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
First Byte: 0x1D -> 29 (# of Data Bytes)
2) 0x14 - : INT_EVENT1
write to 0x20 ack data: 0x14
read to 0x20 ack data: 0x0B 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01
First Byte: 0x0B -> 11 (# of Data Bytes)
Please do refer to section 1.3.2 Unique Address Interface Registers in the Technical Reference Manual.
Hope this helps.
Regards,
Deepak
I have confirmed by reading register 0x03 that the device is in APP mode. I am reading back 4, 65, 80, 80, 32.
My I2C address for TPS25750 is 0x21 as defined by ADCIN1 and ADC2 both connected to 1.5V, decoded value #2 = 0x21
I am trying to perform "I2Cr" on slave device BQ25792 (address 0x6B) connected to I2Cm. The steps for this are:
1) Write to device I2Cs DATA1 (0x09) BYTE1=107 (0x6B), BYTE2=28 (0x1C), BYTE3=1
2) Write to device I2Cs CMD1 (0x08) BYTE1= 73, BYTE2=50, BYTE3=67, BYTE4=114 --this is ascii for 'I2Cr'
3) Read I2Cs and should receive 0x1C from BQ25792 (charger_status_1 register)
I am currently stuck at step 1 only because I am not reading back BYTE1=107 after writing. Instead of 107, 28, 1, i am getting 64, 28, 1, 0. Is this what I should expect?
Are my steps above ok for doing I2Cr?
Kiran,
The data register (0x9) is 40 bytes long. It contains 16 words (Little Endian).
Please refer example pattern:
Word1: 0x6b1c0100
Word2: 0xeeff1122
Word3:0x33445566
Logic Analyzer Log:
write to 0x20 ack data: 0x09 0x40 0x00 0x01 0x1C 0x6B 0x22 0x11 0xFF 0xEE 0x66 0x55 0x44 0x33 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Please note, the first byte that is being sent is the address of the register. The second byte is the length of bytes, followed the data.
read to 0x20 ack data: 0x40 0x00 0x01 0x1C 0x6B 0x22 0x11 0xFF 0xEE 0x66 0x55 0x44 0x33 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Please use this as reference to perform I2C read/writes.
If the writes to register 0x9 are performed correctly. Then the I2Cr (4CC Command) would output the data on the master line.
Regards,
Deepak
Yes. The second byte sent represents number of data bytes. You can always specify the length of bytes you would need for write/read.
Thanks for you help so far..
Would I2Cr output results on master line or slave (back to mcu). It is the mcu (on I2Cs line) sending request to read therefore I would expect data to be sent back to mcu on I2Cs. If this is not the case, how can this data be sent to the mcu via I2Cs?
Hi Kiran,
Executes I2C read transaction on I2Cm. The 'I2Cr' task may be used to cause the PD controller to read from a specified slave address and register offset using a I2C read transaction via the I2Cm_SDA and I2Cm_SCL pins.
Please refer to 3.4.2 'I2Cr' - I2C read transaction in the technical reference manual.
Also note, you do not have to read and write all 64bytes (0x40) of the data register. You can always specify the length of bytes you would need for write/read.
Regards,
Deepak
I am now able to successfully write to register 0x09 (DATA1) and confirm by read that this is [64, 107, 28, 1]. This is address 107 (0x6B), register 28 (0x1C), bytes 1.
I am also able to write to register 0x08 (CMD1) and confirm by read that this is [4, 73, 50, 114]. This is ascii I2Cr.
I expect 2 things to happen following this transactions,
1) 0x08 (CMD1) should be cleared to 0x00
2) 0x09 (DATA1) should return the data readback from BQ25792 device (address 0x6B)
Neither of these is happening.
I know the CMD1 is being written and readback correctly because if i write an invalid command e.g. [4, 74, 50, 114], i read back [4, 33, 67, 77, 68] which is !CMD.
I suspect its the DATA1 value that is causing an issue. To read register 0x1C from BQ25792, assigned to Charger_Status_1, Should DATA1 be set to [64, 107, 28, 1]?
Also, in reference to my previous query, I understand I2Cr will read on master line but should i expect this command to output results back to mcu on I2Cs? And this should be on DATA1 register 0x09?
Kiran,
The output from the TPS25750 will output the read results on the I2C master lines.
Please can I get information on the application. It would help me understand better and provide a better solution. Block diagrams and logs would be helpful.
Also please do refer to this application article to confirm if you are implementing an integrated or non - integrated solution. From our conversation I believe its a non-integrated solution. But Please do confirm.
Regards,
Deepak
We have an integrated solution identical to TIDA-050047 except with TPS25750S. Trying to charge 3 cells and at the moment charging current is at default 1A.
Link to TIDA-050047: TIDA-050047 reference design | TI.com
I need to update ICHG on BQ25792 to allow higher current.
I have followed technical reference manual for TPS25750, set DATA1 and CMD1.
If I set DATA1 to 64, 107, 53, 2 (64 bytes, slave address 0x6B, register 0x35, 2 byte count)
and CMD1 to 4, 73, 50, 67, 114 (4 bytes, I2Cr)
DATA1 stays set to 64, 107, 53, 2
and CMD1 stays set to 4, 73, 50, 67, 114
both confirmed by performing read operations to registers DATA1 (0x09) and CMD1 (0x08)
I expect DATA1 to contain data read from BQ25792
and CMD1 to readback 0x0000
I have looked at scope captures to debug and found that after setting DATA1 and CMD1, the I2Cm bus sends 6B (read), 53, 2 BQ25792. Couple of issues I noted:
1) There is stop conditions after this
2) why is TPS25750 sending 2 (byte count) to BQ25792. Is this expected?
Thanks for your support so far. Please confirm my expectations are correct and help with my queries.
Kiran,
Could you please send me the I2C trace. I will have to look into it and get back to you.
Meanwhile, I had a question, have you tried using the GUI available for the TPS25750. Using the GUI and a scope/logic analyzer should give you a clear picture on what is happening. This also lets you know if your sending the messages in the expected format.
Regards,
Deepak
7848.I2C trace for 4CC command issue.pdf
Tried that gui but could not get the hardware to connect via serial. Not sure what hardware (cables) are needed. The user guide for this GUI does not state what cable and connectivity is required.
I have attached the I2C trace
Kiran,
Thank you very much for the trace.
Tried that gui but could not get the hardware to connect via serial. Not sure what hardware (cables) are needed. The user guide for this GUI does not state what cable and connectivity is required.
Are you using an EVM to do this ??
No i am not using EVM.
Sorry I re-attached the slides a few times due to error. Please refer to latest attachment.
Kiran,
Thank you for the logs as they helped in understanding the issue as I currently do not have a BQ25792 to recreate your issue.
Your Question form Slide 2: (Also addresses your previous questions)
"There is an additional character ‘2’ transmitted after this ?"
Yes there would be an additional 0x02 transmitted after the transmission of 0x6B (address of charger), 0x35 (VBUS ADC). The reason is what is stored in Data1 register of the TPS25750 device will be transmitted to the charger. In your case Data1 register is set to [0x40, 0x6b, 0x35, 0x02].
From going through the datasheet of the charger (BQ25792) and from slide1, you could only use the address of the slave device and the register address, this will emulate what you sent in slide 1.
- Deepak
I have tried missing out the 2 and still no data returning from BQ25792 on I2Cm and DATA1 (0x09) remains 64, 107, 53 (see slides 3 & 4)
I went further and tried to insert 107-r (215) at the end (this is an attempt to simulate bus activity on I2Cm that matches slide 1). Still no data returning from BQ25792 on I2Cm and DATA1 (0x09) remains 64, 107, 53, 215 (see slide 5).
We are missing a stop/start or repeated start before 107-r and there is no way I can force that.
Please let me know if you have any more ideas.
Kiran,
I am currently held up with few other things on my end. I did take a look at your slides, but could not work on it.
I believe the questions regarding 4CC commands have been answered for this thread. You could thereby close this thread.
I would request you to open a new thread for the communication related to BQ25792 and the PD controller. I believe an engineer working on the BQ25792 could help. Please do send me a mail with a link to the new thread as I could keep track of it.
Deepak