• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 63 subscribers
  • Views 469 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.

BQ76PL455A-Q1: Single device write with response

Nick Hartley
Prodigy 125 points
Part Number: BQ76PL455A-Q1

I have made a battery management system using PIC18F45K22 and BQ76PL455A-Q1 on one board. It wakes up all other BQ chips in the stack (tested up to 8 successfully so far), auto-addresses them, sets up registers, reads 16 cells and two temperature sensors per battery/BQ and displays results on a 2 x 16 LCD showing max, min and average cell volts and degrees C.  It can also switch relays to indicate over- and under- voltage or temperature and outputs all data to PC via RS232 to USB converter every 10 sec.  So far so good. 

As a first step to fault handling I'm having trouble reading the FAULT_SUM, FAULT_COM, FAULT_SYS and FAULT_DEV registers, despite using the same routines which work successfully with auto-addressing, etc.  I use for example 81 06 5E 01 31 9D  for BQ address 06 (top of stack), FAULT_COM register, 2 bytes expected, CRC.  There is no response! In the TI BQ76PL455software.pdf guide there seems to be some inconsistency:  

81 02 52 01 755C     Single Device Write With Response (8-bit register addressing), Device Address 2 (top of stack), Register 82 (FAULT_COM register), Expected data bytes: 1,  CRC   but surely FAULT_COM register contains 2 bytes (at 52h and 53h) so it should be 02 not 01?  Either way I get no response.

In general, what recommendation do you make for error detection and handling?



  • 0
    TI__Genius 17370 points
    Hi Nick,

    Thanks for the question and sorry to hear the difficulties. To start, the command shown in the software guide for reading the fault is to the FAULT_SUM register rather than FAULT_COM and the example is just reading the first byte but you can easily change the bytes to 2 if you want to read the full register.

    As for not receiving any response, please make sure the device is active and has been auto addressed successfully first before sending the commands and try talking to device 0 first before attempting to the top of the stack and move up one by one from there. Are you able to read from other registers besides the fault ones?

    Regards,

    Taylor
  • 0 in reply to Taylor Vogt
    Prodigy 125 points

    Hi Taylor,

    Thanks for your help.   I tried addressing device 0, which is actually the BQ76 chip in my control unit.  That worked and I made the discovery that the stack boards had powered down.  This is a problem I thought I had overcome by sending command F1 28 CB OE 64 soon after the wakeup sequence. It sets the two timeouts at 30 and 10 minutes. (I want the boards to power down eventually if the control unit is off so as to minimise battery drain).  Despite this, I still find boards going to sleep after a minute or two.   My program has a comms timeout of 1.25 ms but doesn't report it, so the data processing (min, max, average, relay switching...) continues to work on old data.  I'll put a warning in.

    Yes, the boards are auto-addressed successfully and addresses checked. I get a battery count report on the LCD ad the cell voltages read are consistent with DMM readings.

    At the moment the main loop works OK, with correct commands and responses for cell & thermistor data, but after the initial response to FAULT_COM enquiry, there are no more (the program requests FAULT_COM FAULT-SYS and FAULT_DEV data starting with top-of-stack and ending at device address 1).

    Any ideas?

  • 0 in reply to Nick Hartley
    TI__Genius 17370 points
    Hi Nick,

    Ok it sounds like you are on the right track now. I don't fully understand your issue in the last paragraph - so it responds to your first read of the FAULT_COM register but then subsequent reads do not work? Can you send this snippet of this portion of code and check that the device has not yet timed out ? Is there a reason you are doing it this way rather than trying the opposite order or doing a broadcast read?

    Taylor
  • 0 in reply to Taylor Vogt
    Prodigy 125 points
    Problem solved. I got the number response bytes wrong, so my PIC software was timing out. BQ chips are responding correctly. I need to improve my UART routines. All good for now. Thanks for your help.