• State TI Thinks Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 1 answer
  • Subscribers 66 subscribers
  • Views 1631 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

PROBLEM to establish connectivity with BQ78pl114 through SMBus.Please HELP

Brayts
Prodigy 225 points
Other Parts Discussed in Thread: BQ78PL114, BQWIZARD, EV2400

Hello,

I'm using a bq78pl114 to monitor 30 Li-ion cells battery pack, but I have a lot of trouble trying to put the comunications bus working well with the bqwizard V2.5.

The comunications BUS is one SMBus based on I2C and I'm using one iport/USB Adapter (MCC) to connect the master (PC) to the slave IC(bq78pl114).

I am following the SMBus caracteristics explained on bq78pl114 datasheet, I have already checked with the osciloscope the SMBus signals and everything seems to be allright, except the logical level of the data line in the 9º bit of the CLK line (the slave should acknowledge (ack), by puting in the 9º bit of the clock the data line in the logical level "0"), as you can see in the snapshot from the osciloscope that I took.

Why the bq78 don´t do the ack? I don't understand this!?

For my situation, the bq78 it doesn´t work in any of this situations (I guess!):

-The slave device is busy performing a real time task, or data requested are not available.

-The slave device detects an invalid command or invalid data.

-If a master-receiver is involved in the transaction it must signal the end of data to the slave-transmitter by generating an NACK on the last byte that was clocked out by the slave.

(page 20 of the System Management Bus(SMBus)Specification Version 2.0 August 3, 2000).


As we can see in the both signals, they correspond to the slave adress of the bq78pl114 which is in hex 0x16 = BIN 00010110 (page 43 of bq78pl114 technical reference manual - SLUU330).

Once that the bqwizard not allow to try established comunication with others address (when we try to comunicate for the first time with the bq78 we only have the "conection pack(F2)" option), and we don´t have any others configurations to make in this software, how can I have success in comunicate with bq78 through the bqwizard????

I have implemented all the conections in the schematic (page 24 of bq78pl114) related to the pins number:(5,4,26,27,37,38,13,14,18,19,8,25,43,39,42,44,47 and 48).All of this are necessary for the conection?

It's imperative the use of the battery's in the pins 39, 42, 44 and 47? Or I can use laboratory power supply to simulate the batteries?

Best regards,

Brayts

  • 0
    TI__Prodigy 480 points

    Unfortunately, a nack of device address is a bad problem to have because it is the same error as having no fuel gauge connected at all. So your problem could be that the fuel gauge is not connect or powered correcty or I expect the most likely problem is a ground is not connected or there is too much capacitance or load on the smbus lines because the scope plot you sent has a VERY slow rise time on each bit. That indicates too weak of pullups or something of that nature wrong in the communication circuit.

  • 0 in reply to TravisN
    Prodigy 225 points

    I already check my circuit, and I found which caused the NACK that I talk about in the first post in this topic.

    However the signal that I get on the oscilloscope from the SMBus still the same, with the same caracteristics. (And I remember that I respect the SMBus caracterisctcs, like the value of the pull-up...etc, and I'm using the iPort/USB from MCC to establish the comunication, which is recomended by texas instruments in bqwizard User's Guide and bq78pl114 8S EVM User's Guide).
    Any else ideas for the shape of the wave besides those that TravisN sugested? (see image in the first post)

    So now the bqwizard reconize de slave bq78pl114, but the conection fails few seconds later!!? This meens that the bq78 responds to the command (slave address) sent by bqwizard (PC) but then he stops responding!!?Why this hapen?

    Next I present a series of images (bqwizad window -> oscilloscope), so you can understand better what I'm trying to say:

     (He says loading application)

    (But then fails the conection, however if you notice in the left top of the window says:"Texas Instruments-bqwizard2.5Build(7):bq78PL114", which means that bqwizard recognized the slave, right?)

    After the connection is successfully established should not show anything of this kind (example):??? (To me don't appears any data, just the names of the tabs in the main window of the bqwizard!)

    I have implemented all the conections in the schematic (page 24 of bq78pl114 datasheet) related to the pins number:(5,4,26,27,37,38,13,14,18,19,8,25,43,39,42,44,47 and 48).All of this are necessary for the conection is successfully established ?

    From the same schematic, which links have to be made to achieve information as it appears in the last picture I have presented? (The connections related to the control charge mechanism, cell balancing, and LED's display are mandatory to I get this information???)

    Another thing, what exactly means this warning?(I try to do some operations that bqwizard offer and than this appears).How can make this warning disappear?

    (Says:"Cannot perform writes to flash when the 'wired' bit is no set")

    Please if possible to answer ALL my questions, I realy need to put this working well.

    Best Regards,

    Brayts

  • 0 in reply to Brayts
    Prodigy 225 points

    Hello everyone,

    Someone please clear up the doubts raised in this post.
    Have read and reread all the documents related to this equipment and I can not solve my problems ... =s

    Best regards,
    Brayts

  • 0 in reply to Brayts
    TI__Prodigy 480 points
    I suspect the com port for the MCC dongle got assigned higher than COM16.  This usually happens when a Bluetooth interface is present. BT is a com port hog.
     
    Simply change the port to 16 or lower. It is OK to have it sit on top of a BT port.  I have done this many times.
     
  • 0 in reply to TravisN
    Prodigy 225 points

    Hi,

    (the COM port of the MCC dongle had the value COM5), anyway, I already change the number of COM port to 16 or lower, but the problem remains.

    Any other sugestions?

    Best regards,
    Brayts

  • 0 in reply to Brayts
    TI__Prodigy 480 points

    I have talked to some people about this because I am unfamiliar with the Software and dongle for this part.  The part is not communicating correctly here and if we fix that issue then all others will be fixed.  You have to go back to the original scope plot you sent me.  This is not a good communication picture.  There is some capacitive load that is really killing the rising edge of each clock and data transition.  You have to find this problem with your circuit board or you will not get this to work. 

    Some things to look at:

    1. If you have another bq78pl114?  As a last resort you could try another one in case the part is damaged.
    2. Have you tried this on an EVM or is it your own circuit board.  Please try on an EVM first and see fi it works there.  
    3. Try a different circuit board
    4. Look at the data that comes out of the dongle without a fuel gauge connected.  You will get a nack but at least you can see if the transitions on the SMBus lines are fast and clean as they should be.  If they are then the problem is definitely with your board that you are using.   If they are not, then your dongle is not working right. 

    This is about all I can think of, but you have to stay focused on this problem first.  You said you got rid of the nack but it is not working in all conditions apparently.  It is not reliable as it is.   

    BQ78pl114

  • 0 in reply to TravisN
    Prodigy 225 points

    Hi,

    I checked a new circuit board with a fresh BQ78pl114 and I can´t understand what may cause the problem with capacitive load.(I just have implemented the connections related to the pins that I initially said in this post, exactly like are sugested in page 24 of BQ78pl114 datasheet).
       
    However there are some caracteristics related to the dongle (MCC), that affect the shape of the signal that I post initialy in this topic.
    When I read for the first time the MCC Iport/USB User's Guide, I follow precisely the instructions that I present next:



    (The following attempts were preformed initial without the fuel gauge connected, and than with the fuel gauge connected.)

    So I use external pull-up resistor (aprox. 15kohm, NOTE: This value is located in the range mentioned in bq78 datasheet) and I shut off the internal pull-ups of the dongle using the slide switch, and the signal that I get on the BUS is the one that I show in the first post.(Theoretically this should work)!

    I tried the BUS conections using the internal pull-ups (1.8kohm) of the dongle, but the problem remains, however the signal seems more correct as you can see:

    So I return to use external pull-ups, but whith a lower value and the signal is very similar to this one. But once more I was not sucessful.

    I would like to try with the EVM Evaluation Kit but he's not available...

    What is your comments about that results?

    Best regards,
    Brayts

  • 0 in reply to Brayts
    TI__Guru 54715 points

    SMBus and I2C have rise time requirements, the initial view did not appear to meet those. As some references on indicate, some compromise in the pullup value may be needed, particularly with evaluation setups. When using the MCC dongle with bqWizard to talk to the bq78PL114 using the internal pullups of the dongle is expected. Your latest picture appears to have much better rise times.

    In getting the part to work you have 4 areas to work:

    1. The PC execution/communicaiton realm.  You have the com port set correctly & apparently have software & drivers installed. Other aspects are mostly packaged without adjustment. bqWizard uses a lot of communicaiton to configure and display device status, debuggging with a simpler tool may be a good approach.

    2. The Dongle hardware. This is durably packaged and basically not adjustable other than the pullup switch which you are now using. Certainly all products have variation but I would expect this is fine unless it has been damaged.

    3. The interconnect. These can be fragile and cause non-obvious problems. If you have good signal characteristics at the IC perhaps it is OK.

    4. The device & circuit implementation. The device is proven to work with the above items in some implementations.  Devices are subject to damage of course.  The implementation is likely the largest variable with lots of defect opportunities.

    You seem to have covered the critical signals for communicaiton in your pin list.  The device pad should also be connected to VSS. Other unused inputs should be maintained within safe operating limits.  You do not need the balancing circuit or display connected although the display can give an indication of the device operation.  The listing of individual pin connection raises a concern of the integrity of connecitons and the circuit construction. A complex part with a package like this may not work well with some prototype construction methods. Most critical are the cell inputs which form the power supply, the VLDO outputs to suitable capacitors and reset.  Once the supply is applied, confirm the VLDO1 voltage is 2.5V and stable. Once the part comes out of reset and initializes, it should be able to communicate.  If you had the LEDs connected there is an indication during reset, you might be able to see if the device was entering reset repeatedly. If the power supply drops too far the part will shutdown.  If your power supply current limits too low the device may cycle in and out of reset.

    The various screen captures indicate that in some cases bqWizard found the device then lost communication.  Others seem to indicate it did not establish communication. The can't write to flash message indicates it thinks it is to be writing flash but got a wrong bit from a status read, basically it indicates a communication problem.  There is a communicaiton status area in the bottom bqWizard window border which may be helpful. Once your communicaitons are stable, a good part is properly connected and on with stable power and out of reset, it should talk. Once you have reliable communicaitons with the device, you will need further connecitons to get the part operating completely.

     

  • 0 in reply to WM5295
    Prodigy 40 points

    I'm not sure if Brayts has his communications working or not but I also had trouble initially with my communications with the bq78PL114 EVM.

    This worked for me: (It might help others as well...)

    --------------
    My USB dongle had to have new firmware code downloaded to it before it would work correctly with the bq78PL114 EVM…I found the following in a readme file from TI:

     

    The procedures below explains how to load custom firmware on a USB-TO-GPIO
    Adapter so it is compatible with bqWizard.

    Scenario 1 – if the USB-TO-GPIO device still has the original firmware from TI
    1. Unzip (bqWizard Path)\Usb\SAA_Utility.zip to the current directory.
    2. Run (bqWizard Path)\Usb\SAA_Utility\USB SAA GUI.exe
    3. File >> Update Firmware
    4. Select (bqWizard Path)\Usb\SAA_Utility\usb.bin
    5. After the download completes, unplug the USB cable and then plug it back in so Windows will reinitialize the dongle and load the new version.

    Scenario 2 – if the USB-TO-GPIO device was updated to v2.0.x+ and this is a revision
    1. Unzip (bqWizard Path)\Usb\EV2400_Utility.zip to the current directory.
    2. Run (bqWizard Path)\Usb\EV2400_Utility\EV2400 Test Program.exe
    3. File >> Update Firmware
    4. Select (bqWizard Path)\Usb\EV2400_Utility\usb.bin
    5. After the download completes, unplug the USB cable and then plug it back in so Windows will reinitialize the dongle and load the new version.

    Note: Both of the applications mentioned above allow you to test various protocols and configure the USB-TO-GPIO interface adapter. To update the firmware we are only interested in the ‘Update Firmware’ feature that both provide. The rest of the application can be ignored.

    I used Scenario 1 and now my communications appears to be working BUT it found the wrong number of cells...BUT that is another problem...(not communications!)...

  • 0
    Prodigy 10 points

    Hello Brayts,

    I was reading your post and I have the same issue that you reported about the battery would not return the ack. How did you fix that?

     

    Thanks,

     

    Marcelo

     

  • 0 in reply to Marcelo Costa
    Prodigy 225 points

    Hi Marcelo,

    I stop working with bq78pl114 couple years ago, but if I remeber well I solved this problem by connecting the bq78pl114 pin nº31 to the ground.

    Try to do this and then please tell me if you have successful, maybe I can give you some more tips.


    Cumps,

    Brayts

  • 0 in reply to Brayts
    TI__Intellectual 1505 points

    Hi Marcelo,

    There are several posts on the e2e forum on SMBus Communications. You can start with the following post:

    http://e2e.ti.com/support/power_management/battery_management/f/180/p/122551/448669.aspx

    Also refer to the following document that details the SMBus / Sdata Communications:

     http://www.ti.com/lit/an/slua591/slua591.pdf

    Regards

    Ben