• State TI Thinks Resolved
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 264 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.

TM4C129XNCZAD: TM4C129X TM4C Flash Mirror Mode..

Newman
Expert 6015 points

Part Number: TM4C129XNCZAD

Hi Team TM4C,

My customer has the following questions..

We are doing new development for a TM4C129X and the datasheet/TRM is not as clear as we need to be about flash mirroring (https://www.ti.com/lit/ds/symlink/tm4c129xnczad.pdf section 8.2.3.3 Pg:641).

We want to execute operational code from the lower- or upper-half of flash while downloading a firmware upgrade to the other half, and then toggle the mirror-bit for cutover.

Do you have any additional documentation on the functioning of mirror-mode?  The reference manual description is brief and, as noted, somewhat obscure.

For example, the reference manual seems to say that all reads are mapped through the mirroring, in which case it doesn't seem possible to verify correctness of writing the new image (in the other half of flash) before cutting over to it.

As another example, the manual implies assymetric operation between mirror-mode ON and OFF, whereas we were hoping for symmetry -- the mirror-bit selecting between the upper- and lower-halvess for execution, but handling being otherwise symmetric.

 Are there resources or examples for how to do an atomic "toggle mirror-mode and reboot" operation?  Is there a recommendation to have a common bootstrap in both upper- and lower-halves (and thus not field upgradeable) or is it possible to execute from RAM to toggle-and-reboot?

Thanks, Merril

  • 0
    TI__Guru**** 191886 points

    Hi Merril,

    Newman said:
    Do you have any additional documentation on the functioning of mirror-mode?  The reference manual description is brief and, as noted, somewhat obscure.

    Sorry, no additional documentation other than what is described in the datasheet. However, I find these posts that maybe helpful. 

    https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/853620/faq-how-to-use-flash-mirror-mode

    https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/498393/flash-mirror-mode

    Newman said:
    For example, the reference manual seems to say that all reads are mapped through the mirroring, in which case it doesn't seem possible to verify correctness of writing the new image (in the other half of flash) before cutting over to it.

    Before you enable the mirror, you will need to verify the the patched code for the upper address image. 

    Note: After a mirror mode has been executed and the code locations have been swapped from
    the upper memory banks to the lower, the application can continue to read from the lower
    memory bank address locations. However, when erasing or programming the swapped
    memory, the application must use the "real" upper memory address of the code before it
    was swapped. For example, in Figure 8-7 on page 609, when the yellow highlighted location
    0x00.3FE8 is swapped with 0x08.3FE8 the application's next read location is 0x00.3FEC.
    However, if the application were to program or erase the next location it would need to write
    or erase location 0x08.3FEC

    Newman said:
    As another example, the manual implies assymetric operation between mirror-mode ON and OFF, whereas we were hoping for symmetry -- the mirror-bit selecting between the upper- and lower-halvess for execution, but handling being otherwise symmetric.

    I'm not clear as to what you meant by asymmetric for execution and symmetric for handling. I think you have two pretty much identical images at upper and lower halve of the flash. Upper halve is meant to contain the patched code/data. You will need to build your upper halve image with the load address for the upper address and the run address for the lower address.