• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 3 answers
  • Subscribers 35 subscribers
  • Views 1380 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.

TPS65986: Need to clarify Memory Mapping for FW Update Process

Eric S
Expert 5640 points

Part Number: TPS65986

Team, we are still trying to clarify the High/Low Region size, and locations.  It still seems like like the max size of the 'ID, Header, & configuration data' + 'application code' sections is 64kB, and not 68kB like figure 3-4 shows in the FW Update App-Note.

 I say this because using FLrr, I get:

FLrr Region 0 = 0x0000_2000

FLrr Region 1 = 0x0001_2000

 

So, that is only 64kB between each of these regions.  This is especially confusing when the FW upgrade steps ask you to run the FLem command to erase X number of 4kB blocks from the FLrr region address.  In the sample code, it erases 17 4-kB blocks (so 68kB).  If I do FLem starting at 0x0000_2000 using 17 4-kB blocks, I'd erase up to 0x0001_3000, which is supposedly past the start of region 1.

 

Why is the sample code / TI documentation saying the 'ID, Header, & configuration data' + 'application code' sections is 68kB, but based on FLrr, it is 64kB?  When I do a FLem command, should I be erasing 16 or 17 blocks?

 

Based on other response, it looks like the latest config tool can place High Region as low as 0x0001_2000, but is this a limitation of the config tool right now (apparently limiting application code to 60kB, to stay within 64kB max for Header + App Code)...   or is the FW Update documentation incorrect, and the size limit truly is 64kB for Region Header + App Code?

  • 0
    TI__Genius 10370 points
    Hi Eric S,

    One of our engineers should get back to you by Monday.
  • 0 in reply to Aramis P. Alvarez
    TI__Genius 16370 points
    Eric,

    Recommendation is to allocate 68kB each for a low and high region on sFLASH, but the newer versions of the tool assigned 0x12000 for the higher region. This is currently okay since the application code is ~60kB, but we will fix the region-address for the high-region image in subsequent releases of the tool . FYI, the earlier versions of the tool had the high region's address set to 0x20000.

    For updating the low-region/high-region of the image generated by tool v3.10 (and later) over I2C, please use FLem w/ 16 4kB blocks.

    Thanks & Regards,
    Praneet
  • 0 in reply to Praneet Kumar
    TI__Expert 5640 points

    Praneet,

    Thank you for this clarification...  but how does one now manage the FW Update process with future releases of the tool, when the High Region is assigned to 0x13000?  

    When TI does change the memory address of region 1 to start at 0x13000, I think it gets a bit tricky.  If region 1 is active, the upgrade procedure tells us to flash region 0 first.  Since the region size would have grown, flashing region 0 would cause part of region 1 to also be erased.  This means if there was a problem updating the region, we'd possibly end up with both regions 0 & 1 in a non-functional state, which would be bad.  Can you please clarify? 

     

    Is the solution that the Application code size is still <60kB... so we use the new Tool version, and still use FLem w/ 16 4kB blocks.  This will update the FW still being the same size as before, but will effectively "move" the High-Region to 0x13000.   Is this correct?  Then subsequent Update procedures would be able to use FLem w/ 17 4kB blocks??

     

    Thank you for your support. 

  • 0 in reply to Eric S
    TI__Genius 13200 points
    Hi Praneet,

    My customer is facing same issue now. Could you clarify what Eric is asking above?

    Regards,
    Takashi Onawa
  • 0 in reply to Takashi Onawa
    TI__Genius 16370 points
    Eric,

    The problem you described might happen if the sFLASH is programmed w/ a full-flash binary that's generated w/ the older tool (.i.e. Low Region at 0x2000 and High Region at 0x12000), and an attempt is made to update either of these reasons w/ a low-region binary that's generated w/ the newer version(s) of the tool (assuming it generates a 68kB binary).

    When the tool is updated to have the high-region content at 0x13000, update the full-flash binary on sFLASH w/ the image generated by the new tool, and the flash-update application will then work (FLem w/ 17kB blocks)

    Please let me know if it answers your questions - Let me know if you have additional queries.

    Thanks & Regards,
    Praneet
  • 0 in reply to Praneet Kumar
    TI__Genius 16370 points
    Takashi-san, Are your queries answered? Let me know if you have additional queries on the topic other than the ones listed by Eric.

    -/Praneet
  • 0 in reply to Praneet Kumar
    TI__Expert 5640 points

    Praneet,

    What you're telling me to do, seems to be exactly what you said could cause the corruption problem.   The sFLASH will contain a full-flash binary from the old tool, and there is not ability to simply re-write the sFLASH, we're looking to use the FW-Update.   If I update with the binary generated by the new tool using FLem w/ 17 4kB blocks....  then it "could" overlap the regions, if the lower region is programmed first.  This is what we need to avoid.

    How do we use the Flash-Update application to safely do this conversion for the high-region content to start at 0x13000???    I would "think" we would do the following using the Flash-Update procedure:

    1. Use the old 64kB binary generated by the old tool
    2. Run the Flash-Update procedure with the old 64kB binary using FLem w/ 16 4kB blocks, but using the new tool (placing high-region at 0x13000).
    1. This effectively should just "move" the existing high-region to the correct address location
    • Then generate new binary with new tool (I assume it may generate a 68kB binary)
    • Run the Flash-Update procedure again with this new binary, and using FLem w/ 17 4kB blocks.

    Now we have NEW binary with NEW tool, and High-Region at 0x13000.

    HOWEVER...... The question, though, is the correct way to run the update procedure....  because FLrr will return 0x12000 for Region[1], and that pointer value is used in subsequent "erase" and "address" commands.   FLem should be run with that same pointer returned in FLrr command...  but with how many 4kB blocks?   Should they use 17 4kB blocks to ensure that they erase what will become the 16th block when writing from the new start address of 0x13000?
    Now also, FLad should then use address 0x13000, instead of the pointer value returned from FLrr command.  This varies from the app-note procedure, and requires to know if we are currently writing Region[0] or Region[1], and requires modification to the procedure to increment the pointer address.  

    I'm sorry if I'm completely missing something, but I would like to see a robust instruction to migrate to the new tool and 0x13000 address location using the Flash-Update procedure.  We do not have the ability to simply re-write the entire sFLASH binary to get our new starting point in all cases.   Thank you.

  • 0 in reply to Eric S
    TI__Genius 16370 points

    Eric,

    This was exactly my point - As I mentioned in my previous post (and I quote again) "The problem you described might happen if the sFLASH is programmed w/ a full-flash binary that's generated w/ the older tool (.i.e. Low Region at 0x2000 and High Region at 0x12000), and an attempt is made to update either of these reasons w/ a low-region binary that's generated w/ the newer version(s) of the tool (assuming it generates a 68kB binary).".

    I acknowledge this limitation - Full-flash and low-region binaries go hand-in-hand, and I'd expect the sFLASH's content to be rewritten w/ full-flash binary to be able to successfully update the low-region content over I2C. We cannot just support a scenario where the sFLASH is programmed w/ a binary generated by the older tools, and the host attempting to update a region w/ the low-region binary generated by the planned (and yet to be released) newer tool. If you are saying that the customers cannot reprogram the sFLASH w/ the full-flash binary and that they would end up with more problems, we can defer updating the high-region address in the newer versions of the tool - The code+config binary is still within 64kB, and this will fit in the available space we have b/w 0x2000 and 0x12000.

    And, about 'the 16 or 17 4kB chunks' question that you had: To make the implementation/update process more robust, I suggest not to hard-code the # of 4kB chunks either to 16 or 17. The 4B content at offset 0x08 and 0x0C of a region will contain the size of the configuration and code-patch respectively. Ex: *(0x2008)/*(0x12008) is the configuration size and *(0x200C)/*(0x1200C) is the code size, which is currently set to 0x1000 and 0xECBO by the tool - This adds up to the actual size of the low-region binary. Use this data to set the # of 4kB chunks.

    Thanks & Regards,

    Praneet