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.

BQ78350-R2-DEVICE-FW: Reading data of 0xF081 even on sending the write command of 0xF082

Part Number: BQ78350-R2-DEVICE-FW

Hi Team,

I am not getting the proper data on reading the 0xF082. Follwoing are the steps I performed to read data,

1. I am making CAL_EN = 1 of Manufacturing status

2. I am writing the 0xF082 through manufacturing block access 0x44

3. I am reading the 0xF082 through manufacturing block access 0x44

I am getting the status as 1 always in 0xF082 and I see all the data of 0xF081 received while reading 0xF082. However, pefo rming same commnads to read 0xF081 I receive correct data.

i need help how to read the correct data of 0xF082?

Regards,

Shreyas Shroff

  • Hi Shreyas,

    This is strange. Are you sure you are sending the commands correctly to read 0xF082? Can you send me the sequence you are using?

    One thing to note from the TRM is the values are updated every 250ms, so is there a chance you are reading too fast and are reading the previous values?

    Thanks,

    Matt

  • HI Matt,

    Sorry for the late response.I missed your response last week and hence could not give the more details.

    Following is the sequence I use for reading the data from manufaturing access() upon writing 0xF082.

    1. Manufacturing status read to check CAL_EN through manufacturing access():

        Read command --> 0x16 0x23 0x17 0x02 0x00 0x80

    2. Write 0xF082 through manufacturing block access():

       Write Command --> 0x16 0x44 0x02 0x82 0xF0

    3. Read data from 0xF082:

       Read command --> 0x16 0x44 0x17 0x1A 0x82 0xF0 0x15 0x01 0xFF 0x3F 0x86 0x0E 0x89  0x0E  0x88 0x0E 0x8A 0x0E 0x87 0x0E 0x90 0x0E 0x30 0x00 0x62 0x17 0x8C 0x0E 0x8A 0x0E

  • Hi Matt,

    Any feedback with below issue. what can be the cause of not getting the Calibration daat on sending the command 0xF082?

    Regards,

    Shreyas Shroff

  • Hi Shreyas,

    That is very strange. I am unable to reproduce what you are seeing. One thing to watch out for - if CAL_EN is reset somehow, you will read back the data from the last command that was written to 0x44. However, I would expect to see that 0xF081 and 0x1 would show for command and status. You are seeing 0xF082 and 0x1 which is very strange.

    Here is what I am seeing on my EVM: (with CAL_EN set)

    1. Write 0xF082 through manufacturing block access():

       Write Command --> 0x16 0x44 0x02 0x82 0xF0

    2. Read data from 0xF082:

       Read command --> 0x16 0x44 0x17 0x1A 0x82 0xF0 0xA3 0x02 0x07 0x00 .......

    Regards,

    Matt

  • Hi Matt,

    I see that even after making CAL_EN I cannot fetch the latest value after every 250msec from the bq78350. I see that the value do not get refresh as the rolling counter on reading 0xF081 and 0xF082 has always same counter value.

    Can you give me the steps I need to perform to get the rolling counter moving 0xF081 and 0xF082?

    Currently, I am sending the 0x002D command if CAL_en is not set and than reading the value from 0xF081 and 0xF082

    Regards,

    Shreyas Shroff

  • Hi Shreyas,

    One important note in the TRM is: "The device stops reporting calibration data on ManufacturerData() if any other MAC commands are sent or the device is reset or sealed."

    Is it possible you are sending other commands in your code between readings? Also, the command to set CAL_EN toggles this bit, so if CAL_EN was already set, it will set it back to zero.

    Regards,

    Matt

  • Hi Matt,

    I am reading the cal_en status only before sending the 0xF081/0xF082.

    In case, if the calibration stops sending the new data, what is process to restart it?

    I do set Cal_En and than I check the status of Cal_en and than I read 0xF081/0xF082 but by this I see many time the rolling counter is stopped.

    Regards

    Shreyas Shroff

  • Hi Shreyas,

    How long are you reading 0xF081/0xF082 for? The instructions in the TRM say to poll the counter until it increments by 2 before reading the data. This means it should take a little time. 

    Also, were you able to finally get a reading on 0xF082?

    Matt

  • Hi Matt,

    I am reading in a gap of 50msec for 5 times and checking the status bit on read of 0xF081 / 0xF082 to check its validity.

    In between the 50msec on executing this same sequence  I see the rolling counter value is same.

    Hence, I fell some how I am missing the command where I can again restart the ADC calibration value and get the latest value on read of either 0xF081 / 0xF082

  • Hi Matt,

    I know the value gets refresh at 250msec, but as the calibration is not refresh on every time on execution of 0,xF081 and 0xF082 I get same rolling counter.

    and as you are already aware of the 0xF081 value is read on sending the 0xF082 as calibration values are not getting refreshed.

    Regards,

    SHREYAS Shroff

  • Hi Shreyas,

    I'm not sure how to help debug this further since I am unable to reproduce what you are seeing. Can you try this on an EVM and compare your MCU commands with the commands and result from BQStudio?

    Matt

  • Okay,

    Can you help me in understanding how to get the latest value of calibration.

    What is the command in case refreshing of calbration data stops

  • The calibration data should not stop if CAL_EN = 1. You mentioned before that you are reading every 50ms for 5 times - I don't think this is enough time. Remember the counter needs to increment by 2, so you should wait a minimum of 500ms. 

    I highly suggest you do the same sequence with BQStudio to compare to help debug what is different.

    Regards,

    Matt

  • Hi Matt,

    On bqstudio also I am getting the data of 0xF081 on 0xF082.

    Please refer the attached screenshot.

  • Hi Matt,

    In BQstudio also I am getting the same result, where on CAL_En the ADC raw data is not getting refresh. I get the value of 0xF081 on 0xF082.

    Please find the attached screenshot for reference .

  • Hi Shreyas,

    I repeated the same thing and cannot reproduce what you are seeing. I recommend reprogramming the R2 firmware to make sure nothing has been changed.

  • Hi Matt,

    FYI....

    The issue got resolved when I change the power ->sleep-->bustimout from value 0sec to avlue 1sec.

    Thanks for your support.

    Regards,

    Shreyas Shroff

  • Hi Shreyas,

    I'm glad you were able to resolve this. Thanks for following up and letting us know how you solved it.

    Best regards,

    Matt