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.

bq34z100evm and linux/ android

Other Parts Discussed in Thread: BQ34Z100EVM, BQSTUDIO

Hi,

I am using a bq34z100evm an ev2300 and an android beagle bone black device.
I connected our battery pack to the bqEVM +BAT and BAT- connector and tested the connectivity functionality directly with the ev2300 and the bqStudio on a win7 pc. Works fine bqEVM i2c address is 0xaa.

Than i am connecting the sda, scl, and gnd pin of the evm to the beagle bone blacks i2c port.
The N/C pin is still connceted to the ev2300.

I am opening the ic2 port on the beagle bone black android/ linux device with

int fileDescriptor = open("/dev/i2c-1", O_RDWR);

and try to to activate the bqEVM by sending his i2c address

if(ioctl(fileDescriptor, I2C_SLAVE, 0xaa) < 0)
{
    LOGE("i2c: failed to set i2c device address %d fd= %d", 0xaa, fileDescriptor);    
    return -1;
}

this is failing.

I tested the code with an ds1307 rtc over i2c at the !!! identical port and the identical code procedure !!!! and it works great.
Is there something that i miss?

Is the evm not designed to be used in this way?

What should than the bst was to connect the evm with the BBB?

Or why can't i get a connection to the bqEVM?
The i2c frequency is set to 100kHz and as you can see the bqEVM is used as slave.


Thanks in advanced with best regards,

  • Elmar,
    I have not worked with the Beagle, but maybe someone else on the forum can offer some insight. The most common issue that I have heard with 3rd party interfaces is when they do not support clock stretching. The gauge will hold the SCLK signal low when it writes to flash memory or when it needs time to prepare data to send to the host. You will probably need to use an oscilloscope and compare the waveforms between the two setups.

    Tom
  • Hi Thomas,

    really thumps up and a lot of thanks for this fast response.

    Thanks goodness I solved the problem and it has nothing to do with the clock delay.

    The strategy to go over the iocontrol to set the i2c address 0x55(d85) of the bq is correct. But what you must know is that this is not initiating a transmit. What was unknown for me.

    The set is a pure system internal value set. It serves only for later send commands to add automatically the correct id value. The reason why it fails on the beagle bone is that on the i2c2 (p9.19, p9.20) port the ids 84, 85, 86 are used for the eeprom access. Because the id of the bq can't be changed we must connect it with the i2c1 port. and it was working.

    Still I think TI sucks (nicely spoken) with providing example source code. I was absolute unable to find any example code for the bqs.


    Thanks a lot lot Thomas and have a great day.