BQ40Z60: SREC Programming

Let me check with our software and see if we can give you some help.

I am looking forward to the reply.

Best regards

Patrick

Here is some feedback I got from our software team.

bqStudio may not exactly match any documentation because it is not a production tool.

bqStudio queries the bus every few seconds to find out if the device is connected or has changed and sometimes sends additional commands depending on the response. Therefore customer may not see a perfect match by sniffing the bus.

 Hi PatWit!

Have you correctly post the byte sequence?

Normally "SREC complete" transaction should contain 32 bytes payload, excluding PEC byte. In your line it's only 15 bytes.

Best regards.

Hi Igor,

the packages you are talking about are the normal payload.

They are splitted into to parts:

Programming the dataflash -> structure: 0x16 0x0f 0x22 Payload PEC (0x16 = Adr, 0x0f = ROM CMD for programming dataflash (SLUU225))

Programming the instruction flash -> structure: 0x16 0x05 0x22 Paload PEC (0x05 = ROM CMD for programming the instruction flash (SLUU225))

I got those packages during the sniffing and this was very easy to explain, even not all data (rows with 0xFF) are not send.

The problem is that there is some start sequence and an end sequence:

Start for example:

Device in Rom Mode (MAC CMD 0x0F00)

Check if in Rom Mode

Then the CMD's in ROM:

0x16 0x09 0x00 0x00 0x29 (Adr, ROM CMD(set adresse SLUU225), I think adress in ROM, PEC)

0x16 0x0A 0x00 0x00 0x94 (Adr, ROM CMD (write bytes derivated from SLUU225), Value, PEC)

......

And there are many steps like this and at the end for example was the written byte sequence send.

The problem is the SLUU225 is from 2005 and from an other device and not all CMD's are matching the meassured values.

Some CMD's are not even mentioned there (for example: 0x16 0x12; 0x16 0x13; 0x16 0x14; 0x16 0x1A 0xDE 0x83 0xDA)

I think those CMD's are deleting flash and the 0x1A is for activating/deactivating regions.

But nothing is documented, so it is just suggestion :-)

Best regards,

Patrick

Hi Andy,

thanks for the reply.

It is right that the bqStudio queries the bus in normal mode. But during the FW Update this feature should be deactivated.

As i already mentioned: I think it is something that has to be done on the BQ40Z60 chip, like unlocking the chip, erasing, programming, verifying.

I mean the chip is based on somekind of logic with instruction, and they are programmed during the SREC download.

Any information about this would be great.

Best regards,

Patrick

I got an other assumption about the CMD's 0x12 0x13 0x14:

The SREC Files contains datablocks of S3 this means the adresspart is 32 Bit. 

For Example the last datablocks are beginning at the adress 0x00140000. The Part just receives the last 16 Bits and to switch between the different regions of flash the CMD's are needed in ROM Mode.

Can TI provide any confirmation/hints on those ideas?

Best regards

Patrick

Hi Andy,

can you provide some informations about the informations i provided?

Or can you tell me something about my assumptions?

Best regards,

Patrick

I would need to check with the software team again and see if they can provide some info.

Hi Andy,

i would be grateful for any information.

Hi Andy,

thanks for the informations. So i was on the right trace. 

But still i have a question regarding those CMD's -> the responded answer for example CMD 0x14 is 0x50 0xC9 0x8F (after programming the data flash), can this values be calculated?

Also i still do not know how the "final" checksum (0x16 0x03 0x0B 0x2A 0x2A 0x2A 0x7F 0x01 0x00 0x00 0x0A 0x0A 0x01 0x05 0x00 0x7F 0x00 0x48) is calculated.

Best regards,

Patrick

Hi Igor,

thanks for the answer.

I noticed that the responded bytes after the CMD 0x13 are changing regarding the payload of data.

For example if i send 32 times 0xFF (deleting the values at the address) the responded value is 0x26 0xEB 0xDF (the addresses in Flash can change but the answer values stays the same)

If data (not only 0xFF) is send the value of response is changed for example to 0x5B 0x0x3 0x02.

Can this values be calculated or are the fixed regarding the address?

Best regards

Patrick

 Hi Patrick!

CMD 0x13 returns integrity signature for every IFIB block not for hole segment so return value changes every time IFIB block is changed.

As you correctly noted for 0xFFFFFF...FFFFFF 32bytes paylod signature is 0xEB26.

IFIB data is important so signature verified on block basis not for full segment as for Instruction Flash for example.

Yes it could be calculated but algo is complicated.

You could just bypass this step in your tools by readback of written block and comparisation with sent one.

It's good trade-off, as IFIB segment is small you almost not loose in programming time using that approach.

best regards

Hi Igor,

thanks for the reply. Two more question about those IFIB blocks.

I noticed they are programmed in a special order:

0x0020 Data =0xFF *32

0x0040 Data =0xFF *32

0x0060 Data =0xFF *32

0x0000 Data (But the first two bytes are set to 0xFF and are programmed later)

0x0080 Data

0x00A0 Data = 0xFF*32

0x00C0 Data = 0xFF*32

0x00E0 Data = 0xFF*32

After this sequence:

Programm the first two Bytes on address 0x0000

Is there a special reason why this order? Because it would be much easier to just read the srec and programm in the order 0x0000 0x0020 0x0040.....

Why are the first two bytes of the address 0x0000 replaced by 0xFF and programmed later? (I assume this could be the starting address of the FW or so)

Best regards,

Patrick

Hi Igor,

thanks a lot. I got a lot of useful answers.

Just one more question: Where did you get all those informations from? :-)

Best regards

Patrick