TPS65982: .bin file generated from Application customization tool

Takashi San,

There's no provision in the tool to change these addresses - Why would you want to make this change?

There's no bug in the file generation. As you can see in the 'Flash Memory Organization' picture, Region-1 and Region-2 are located at addresses (RPTR-1+AOFF-1) and (RPTR-2+AOFF-2) respectively. RPTR-2 is 0x2000 (same as RPTR-1), but AOFF-2 is different - See 4B @ address location 0x1FFC.

Thanks & Regards,
Praneet

Hi Kumar-san,

Thanks for your quick response on this.

>Why would you want to make this change?

My customer is looking for how to modify Flash memory data. It seems that there was something wrong in their .bin data and they want to update the FW from EC.

There's no bug in the file generation. As you can see in the 'Flash Memory Organization' picture, Region-1 and Region-2 are located at addresses (RPTR-1+AOFF-1) and (RPTR-2+AOFF-2) respectively. RPTR-2 is 0x2000 (same as RPTR-1), but AOFF-2 is different - See 4B @ address location 0x1FFC.

Make sense!. AOFF was always "00 00 00 00" in the document below, so I almost forgot the offset.
Are there any manners in the numbers selection between RPTR and AOFF? eg; RPTR address should be same and so on.

TPS6598x FW Update From Embedded Controller Over I 2C
http://www.tij.co.jp/jp/lit/ug/slvuah7b/slvuah7b.pdf

Also, Could you comment on the question below?

Which part must be modified in order to rewrite Region1 properly?
I believe that it is only to rewrite the following two points though, let me confirm if this understanding is correct or not  just in case.
1. Region1 Pointer address and header + AOFF(0x001000~0x002000)
2. Application code and its header(RPTR + AOFF for Region1 ~ end)

Regards,

Takashi Onawa

Takashi San,

Please refer the document @ www.ti.com/.../slva783a.pdf, which has all the details about the flash update sequence.

The inactive region shall be updated. FLrr command returns the address of the (queried) region in the full-flash binary, and the host application is expected to update the contents at that address w/ the content in the generated 'Low Region' binary.

Please refer the document that I pointed above, and let me know if you have any queries.

Thanks & Regards,
Praneet

Hi Kummar-san,

I have a quick question about the address especially Region1.

If they want to set the Region1 app code address to 0x20000, how do we select RPTR and AOFF values? 

Different manners are used in the document and our App custom tool. So they can not judge which is better.

TPS6598x FW Update~ document manner :(RPTR:0x00020000, AOFF:0x00000000)
In this document, AOFF value is always 0x0 and changing PRTR value.

App custom tool  manner : (RPTR:0x00002000, AOFF:0x0001e000)
On the GUI, PRTR value is always 0x2000 and changing AOFF value.

[BackGround]
My customer would utilize the sample software indicated in the document which you attached. In the document,  0x2000 and 0x20000 are allocated for Region0/1 app code. But the default High region address was changed from 0x20000 to 0x12000 in .bit file generation tool on the latest App Custom Tool, so they want to modify the .bin file generated from the latest App Custom Tool.

Regards,

Takashi Onawa

Takashi San,

We changed the location of high-region image from 0x12000 to 0x20000 to save space on sFLASH. I don't understand how this is impacting your customer's use-case.

The EC application needn't care for the location of the 68kB low-region/high-region content in the full-flash binary. FLrr command will return the address of the region that you'd want to update, and the EC application shall just write the 68kB data to that address.

Thanks & Regards,
Praneet

Hi Kummer-san,

RegionUpdate82() function in the document only allows EC to update region data when the addresses are 0x00002000 and 0x00020000. They referred to that point also when coding their software in EC.
That's the reason why they are seeking the way to change the address of the .bin file. They can not update High region image due to the change.

If we can say either of the following two cases is acceptable and doesn't make any side effects by the changes in the RegionUpdate82() operation, they do not need to edit the .bin file.

Which is easier for you, comment for the address change or RegionUpdate82() review?

[Case1]
const uint32_t rgnPntrVal[2] = {0x00002000, 0x00020000}; -> const uint32_t rgnPntrVal[2] = {0x00002000, 0x00012000};

[Case2]
if (tempData == rgnPntrVal[rgnNum]){} -> delete

Regards,
Takashi Onawa