• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 63 subscribers
  • Views 134 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.

BQ76972: BQStudio hexdump is incomplete

Pablo B
Prodigy 10 points
Part Number: BQ76972
Other Parts Discussed in Thread: BQSTUDIO

Tool/software:

Hello,

I am exporting a hexdump for the above part in BQStudio but the file is incomplete.

The DATAMEMORY section, which is the one I need to program the device cuts at 0x9327, but the actual section should extend far beyond that address.

The goal is to automate programming the device with the host. I would like to load the contents of this section into a C array, enter config update, send its contents 32 bytes at a time, exit cfg update, and done. This works great, except for the part in which we are missing half of the configuration data.

Is there a way to extract the full DATAMEMORY section? I believe I could extract it from the fs file, but it is not as straightforward.

Thanks!

  • 0
    Prodigy 10 points

    I need to correct myself, it's only a few bytes that are missing. I believe the last one is 0x9342, not present in the hexdump and a few others before that.

  • 0 in reply to Pablo B
    TI__Expert 5090 points

    Hi Pablo,

    I understand from others that they have seen this be an issue in the past.  I'm not sure what the root cause of that is, that will take some deeper digging and debug to understand and then determine how to address it.

    For your case, it is probably best if we can work around it in the meantime.  One option would be to craft a flashstream control file to read the full data memory, in 32-byte increments, using the subcommand transfer buffer.  Or if you are only missing a few bytes, it may be easier to just use a flashstream control file to read those select bytes.

    Thanks,

    Terry

  • 0 in reply to -Terry
    Prodigy 10 points

    Hello Terry,

    Thanks for getting back to me. Is the "control file" something different than the flashstream file? If it isn't I am afraid I am not as familiar with them to understand the solution described.

    I do have a quick and dirty workaround for myself, which is just copying and pasting the few missing bytes from the bqfs to the hexdump, quite clunky. However, I am looking for a more elegant solution, since this is something anyone in the team should be able to accomplish following simple directions.

    My long term workaround would be parsing the exported bqfs itself. It's just that I had already written a parser for the hexdump before realizing data was missing.

    Is your solution simpler or more foolproof? If so, I am eager to hear of other methods that can be used to program this chip from the host. What techniques do other customers use when not using OTP?

    I appreciate the support.

  • +1 in reply to Pablo B
    TI__Expert 5090 points

    Hi Pablo,

    My idea was that you can write a flashstream script to read data memory values from the device.  Then you can save that as a log from the transaction log in bqStudio on the Command Sequence tab.  You can write 0x3E/3F to start a read at a particular address, then read 32-bytes of data and checksum and length back.  Then when you read again, the device autoincrements and reads the next 32 bytes.

    For example, to read multiple 32-byte groups of DataMemory starting at 0x9180, your flashstream would look like:

    W: 10 3E 80 91
    R: 10 3E 36
    R: 10 3E 36
    R: 10 3E 36
    ...

    The results show up in the transaction log, which you can save to a log file.  You then need a parser to parse that, not sure if that's easier than just parsing the bqfs file, though.

    When programming the device from a host, I think most customers are not writing a full image, but only the bytes they modified from default settings.  That is in their MCU code, I don't really have much background on exactly how that is done.  We do have some sample code on our product folder that might be useful to you in this regard.

    Thanks,

    Terry

  • 0 in reply to -Terry
    Prodigy 10 points

    Alright, I get it now. I think I'll parse the bqfs file mostly because it saves me steps: export, run parser, done.

    I did that once of only writing the registers needed to change, but maintaining changes in configurations becomes messy and error prone, so does reviewing code changes and comparing them to the full configuration. My goal is to eliminate that risk by automating the process.

    This answers my question. Thanks again Terry for the support.