• State
  • Locked Locked
  • Replies 27 replies
  • Subscribers 63 subscribers
  • Views 524 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.

BQ27421-G1: Unable to unseal the chip

Pavlo Shchipanskyi
Prodigy 10 points
Part Number: BQ27421-G1
Other Parts Discussed in Thread: EV2400

Tool/software:

Hello!

I am writing firmware for the NRF52832 controller with Nordic SDK. In general, much already works, but some problems have arisen.

I have implemented and tested command input via control (reading statuses and flags, reset commands, BAT_INSERT command, etc.). But for some reason, the sealing and unsealing commands via control do not work. I managed to seal via memory access(UPDATE_STATUS |= 0x80). After that, I cannot unseal the device via control. What can I provide to better describe the situation? What should I pay attention to?

The default value of the unsealing key was checked. The unsealing command is sent twice in two multibyte transactions (and single ones were also checked).

Is it important in what state the training cycle is carried out (sealed or unsealed)?

How good is this monitor for systems with a 30mAh battery and an average current of 20-100μA? I noticed that the units are "mA" and there is nothing for "μA".

Best regards!

  • 0
    Prodigy 10 points 

    typedef enum
{
	BQ27421_REG_CONTROL					= 0x00,
	BQ27421_REG_TEMPERATURE 			= 0x02,
	BQ27421_REG_VOLTAGE 				= 0x04,
	BQ27421_REG_FLAGS 					= 0x06,
	BQ27421_REG_REMAINING_CAPACITY      = 0x0C,
	BQ27421_REG_AVERAGE_CURRENT			= 0x10,
	BQ27421_REG_AVERAGE_POWER			= 0x18,
	BQ27421_REG_SOC 					= 0x1C,

	BQ27421_REG_OP_CONFIG				= 0x3A,
	BQ27421_REG_DESIGN_CAPACITY			= 0x3C,
	BQ27421_REG_DATA_CLASS				= 0x3E,
	BQ27421_REG_DATA_BLOCK				= 0x3F,

	/**********Data Memory Access**********/

	BQ27421_REG_DATA_MEMORY_DESIGN_CAPACITY_MSB = 0x4A,
	BQ27421_REG_DATA_MEMORY_DESIGN_CAPACITY_LSB = 0x4B,

	/********Data Memory Access End********/

	BQ27421_REG_BLOCK_DATA_CHECK_SUM	= 0x60,
	BQ27421_REG_BLOCK_DATA_CONTROL		= 0x61,

} bq27421_reg_t;

typedef enum
{
	BQ27421_CONTROL_STATUS 				= 0x0000,
	BQ27421_DEVICE_TYPE					= 0x0001,
	BQ27421_CHEM_ID						= 0x0008,
	BQ27421_BAT_INSERT					= 0x000C,
	BQ27421_SET_CFGUPDATE				= 0x0013,
	BQ27421_SHUTDOWN_ENABLE 			= 0x001B,
	BQ27421_SHUTDOWN 					= 0x001C,
	BQ27421_SEALED						= 0x0020,
	BQ27421_RESET						= 0x0041,
	BQ27421_SOFT_RESET					= 0x0042,
	BQ27421_UNSEALED_PART				= 0x8000,

}bq27421_cntl_t;

bq27421_status_t bq27421_write(bq27421_reg_t reg, u16 value)
{

 u08 data[2] =
 {
    (value >> 0) & 0xFF,
    (value >> 8) & 0xFF
 };

 if (i2c_write(BQ27421_ADDR, &reg, 1, data, 2) != I2C_STATUS_OK)
 {
    NRF_LOG_ERROR("bq27421_write error");
    return BQ27421_STATUS_WRITE_ERROR;
 }

 time_sleep(MS(1));
 
 return BQ27421_STATUS_OK;
}

bq27421_status_t bq27421_control_write(bq27421_cntl_t sub_cmd)
{
 if (bq27421_write(BQ27421_REG_CONTROL, sub_cmd) != 0)
 {
    return BQ27421_STATUS_WRITE_ERROR;
 }

 return BQ27421_STATUS_OK;
}

bq27421_status_t bq27421_unseal()
{
    bq27421_control_write(BQ27421_UNSEALED_PART);
    return bq27421_control_write(BQ27421_UNSEALED_PART);
}
  • 0 in reply to Pavlo Shchipanskyi
    TI__Mastermind 28490 points

    Hi Pavlo,

    How quickly are the two bytes for the unseal being sent? These must be sent within a 4s window of each other. 

    Regarding the uA current, the coulomb counter will be able to detect this, but the firmware will have difficulties seeing this low of a current. What is the sense resistor being used in this design?

    Regards,

    Anthony

  • 0 in reply to Anthony
    Prodigy 10 points

    Hi Anthony, thank you for your reply!


    The keys are sent consecutively, with no other data being written to the Control() register in between, as recommended by the datasheet. These are two multi-byte i2c transactions. The pause between commands is several milliseconds. But I tried to increase the pause between sending commands to 0.1-1 second. I have attached a logical analyzer graph.



    The sensor resistor is 7 mOhm.

  • 0 in reply to Pavlo Shchipanskyi
    TI__Mastermind 28490 points

    Hi Pavlo,

    Thank you for sharing the image, is there any difference if a single byte method is being used?

    Regards,

    Anthony

  • 0 in reply to Anthony
    Prodigy 10 points

    Yes, I tried the single byte method as described in the parameter update example table. I didn't get any noticeable difference, the result was the same.

  • 0 in reply to Pavlo Shchipanskyi
    TI__Mastermind 28490 points

    Hi Pavlo,

    Thanks for confirming, I recreated a successful unseal on one of our boards to where the logic capture can be found below:

    First command:

    Second command:

    Delay between:

    What is the clock frequency at this time?

    Regards,

    Anthony

  • 0 in reply to Anthony
    Prodigy 10 points

    Hi Anthony, 
    Thanks for the images!
    At this time the frequency is 100 kHz. Should it be reduced?

  • 0 in reply to Pavlo Shchipanskyi
    TI__Mastermind 28490 points

    Hi Pavlo,

    Thanks for confirming, 100kHz should be fine here. Would it be possible to get a closer image of the two commands sent so we can check?

    Also, do you have an EV2400 to where this can be checked with a different host?

    Regards,

    Anthony

  • 0 in reply to Anthony
    Prodigy 10 points

    Hi Anthony, 
    I'm attaching a more detailed image of both commands from the image above.





    Unfortunately no, I can't check with another host right now. Based on the graphs above, is it possible to understand the relevance of testing with another host? Perhaps I can get some COM-I2C.

    Thanks!

  • 0 in reply to Pavlo Shchipanskyi
    TI__Mastermind 28490 points

    Hi Pavlo,

    Thanks for sending the closer images, it seems like our logic analyzer captures are close to identical. I will consult our team to see if there is anything missing. Just to confirm, is this currently reproducible on multiple devices?

    Regards,

    Anthony

  • 0 in reply to Anthony
    Prodigy 10 points

    Hi Anthony,

    Thank you, I will wait for feedback. Yes, this currently reproducible on several version A devices and at least one version B device.

  • 0 in reply to Pavlo Shchipanskyi
    TI__Mastermind 28490 points

    Hi Pavlo,

    A couple more questions:

    What are the pull up resistor values at this time?

    What is the cell voltage at this time of trying to unseal?

    Has the delay between commands been tried by extending past 1s?

    Regards,

    Anthony

  • 0 in reply to Anthony
    Prodigy 10 points

    Hi Anthony! Sorry for the delay in replying.

    The value of the pull-up resistors is 10 kOhm.
    The cell voltage was from 3.5 to 4.35 (for version B), the work was carried out on the entire range.
    Yes, I tried to implement a delay of 1 second

  • 0 in reply to Pavlo Shchipanskyi
    TI__Mastermind 28490 points

    Hi Pavlo,

    Thank you for confirming, those values should not be causing an issue. Is there any difference here if the firmware is reflashed and the key is sent again?

    Regards,

    Anthony

  • 0 in reply to Anthony
    Prodigy 10 points

    Hi Anthony.
    No, no difference was found. If I managed to Seal the chip through access to RAM (update status | = 0x80), then Unseal was never performed. Only turning off the power helps.

    I’ll also clarify whether a small battery capacity (30mah) can cause a problem? Built -in sensitive resistor - 7mohm.

    Thank you!

  • 0 in reply to Pavlo Shchipanskyi
    TI__Mastermind 28490 points

    Hi Pavlo,

    If the device is able to be read and written to this time (prior to sealing), I do not think there should be an issue with the small battery capacity. If this is connected to a scope, would the specifications be met below?

    Regards,

    Anthony

  • 0 in reply to Anthony
    Prodigy 10 points

    Hi Anthony,
    Yes, I was able to connect with an oscilloscope and I had some problems with the rising edges and consequently the duration of the low and high levels of the clock line. I lowered the clock frequency to 50 kHz and the resistance of the pull-up resistors for testing. Unfortunately, this did not help. I can still seal the chip via memory access, but I cannot unseal the chip with the key command.
    Thank You!

  • 0 in reply to Pavlo Shchipanskyi
    TI__Mastermind 28490 points

    Hi Pavlo,

    During this time, are all the commands being sent to the gauge receiving ACKs as well?

    Regards,

    Anthony

  • 0 in reply to Pavlo Shchipanskyi
    TI__Mastermind 28490 points

    Hi Pavlo,

    During this time, are all the commands being sent to the gauge receiving ACKs as well?

    Regards,

    Anthony

  • 0 in reply to Anthony
    Prodigy 10 points

    Hi Anthony,
    Yes, all the commands being sent to the gauge receiving ACKs.

  • 0 in reply to Pavlo Shchipanskyi
    TI__Mastermind 28490 points

    Hi Pavlo,

    Thanks for confirming, this is odd since the gauge is acknowledging each of the commands being sent. You said previously that there are multiple units where this is occurring, however are there any units from your end that this functionality is working correctly? If so, are there any distinguishable differences in setup or configuration?

    Regards,

    Anthony

  • 0 in reply to Anthony
    Prodigy 10 points

    Hi Anthony,

    There were three devices with chip versions A and B. Five more devices are expected soon. None of these devices were able to be unsealed. Although I do not receive any errors in the protocol (for example, ACK). Some values ​​were specifically controlled by reading immediately after writing.

    Other problems arise (for example, with the primary conditions for completing the charge and the learning cycle), but this would be a topic for another discussion and I have not written anything yet.

    In addition, it seems to me that such a small battery capacity still causes problems in the state of charge algorithm or in my application. The battery monitor chip sometimes gives very strange unstable charge of state. If you load the battery with an LED and then release it, the voltage is restored, and the percentages can change in one direction or another by tens of units.

    Thanks!

  • 0 in reply to Pavlo Shchipanskyi
    TI__Mastermind 28490 points

    Hi Pavlo,

    Understood, thank you for the clarification. We can take a look at the schematic as well to see if there is anything that stands out at this time. Please let us know what the results from the new chips are as well.

    Regards,

    Anthony

  • 0 in reply to Anthony
    Prodigy 10 points

    Hi Anthony!

    Is this scheme enough? The srx_bat contact also receives charging. There was a GLF73910-BD01 protection chip between the battery and the fuel gauge, but it is now shunted.


    As soon as there is news about new devices, I will write whether there are changes or not.

  • 0 in reply to Pavlo Shchipanskyi
    TI__Mastermind 28490 points

    Hi Pavlo,

    Thanks for sending this image, I do not see any issues with how the communication lines are set up. Are there any components intermediate between the host and gauge on these lines or just the pullups?

    Regards,

    Anthony

  • 0 in reply to Anthony
    Prodigy 10 points

    Hi Anthony,

    There are nothing, just the pullups.

    Thanks!

  • 0 in reply to Pavlo Shchipanskyi
    TI__Mastermind 28490 points

    Hi Pavlo,

    Thanks for confirming, are their any oddities not shown on the board with the I2C lines? Maybe very long routes between the host and device?

    Regards,

    Anthony