• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 82 subscribers
  • Views 440 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.

TMX 28035 Errata

Louis S
Intellectual 325 points

I am currently prototyping on a TMX320F28045PN (part of a ControlCard) and just came across the errata for the Rev 0 silicon I'm using.  Of the features I'm using, I should expect to see based on http://focus.ti.com/lit/er/sprz295b/sprz295b.pdf:

1) Issues with the first ADC conversion in a sequence.  My implementation currently monitors 6 ADC channels in 2 different conversion sequences and hasn't run into any conversion issues yet.  Possibly just lucky, will be investigating that further.

2) Prefetching past valid memory at the end of M1 causing indeterminte states.  Also, likely I've just gotten lucky there.

3) CSM locking activated by reads of 0x3D7FF8 through 0x3D7FFF.  Now, since the prefetching erratat from section 2 will prefetch past the end of Flash A (last section of Flash memory, directly preceeds CSM locations), I would expect to see an issue from the branch instruction in my BEGIN section (chunk of linker cmd file below).

   FLASHA      : origin = 0x3F6000, length = 0x001F80     /* on-chip FLASH */
   CSM_RSVD    : origin = 0x3F7F80, length = 0x000076     /* Part of FLASHA.  Program with all 0x0000 when CSM is in use. */
   BEGIN       : origin = 0x3F7FF6, length = 0x000002     /* Part of FLASHA.  Used for "boot to Flash" bootloader mode. */
   CSM_PWL_P0  : origin = 0x3F7FF8, length = 0x000008     /* Part of FLASHA.  CSM password locations in FLASHA */

I haven't seen any mysterious locking so far, so are prefetches not reads as far as CSM is concerned?  Or is it possible that the prefetch isn't occuring?

Please let me know if there is any additional information I can provide.

Regards,
Louis

  • 0
    TI__Guru* 91940 points

    Louis S said:

    3) CSM locking activated by reads of 0x3D7FF8 through 0x3D7FFF.  Now, since the prefetching erratat from section 2 will prefetch past the end of Flash A (last section of Flash memory, directly preceeds CSM locations), I would expect to see an issue from the branch instruction in my BEGIN section (chunk of linker cmd file below).

       FLASHA      : origin = 0x3F6000, length = 0x001F80     /* on-chip FLASH */
       CSM_RSVD    : origin = 0x3F7F80, length = 0x000076     /* Part of FLASHA.  Program with all 0x0000 when CSM is in use. */
       BEGIN       : origin = 0x3F7FF6, length = 0x000002     /* Part of FLASHA.  Used for "boot to Flash" bootloader mode. */
       CSM_PWL_P0  : origin = 0x3F7FF8, length = 0x000008     /* Part of FLASHA.  CSM password locations in FLASHA */

    I haven't seen any mysterious locking so far, so are prefetches not reads as far as CSM is concerned?  Or is it possible that the prefetch isn't occuring?

    It is the flash prefetch buffer that causes the issue for this case.  The flow is typically:

    • reset
    • boot ROM code runs and determines the boot mode - assume it is jump to flash
    • branch to location 0x3f7ff6 - entry point into flash (i.e. the BEGIN section)
    • take branch programmed at 0x3f7ff6 to redirect the program flow to the start of the application
    • configure device, including enabling flash prefetch

    Since this branch is taken before the application configures the flash prefetch you will not be prefetching into the CSM area.   

    Louis S said:
    2) Prefetching past valid memory at the end of M1 causing indeterminte states.  Also, likely I've just gotten lucky there.

    This is caused by a prefetch mechanism in the CPU itself and is something that doesn't cause an issue in every case - so yes, you've been lucky.  It is safest to honor the errata and keep code away from the end of a defined memory block.

    I'm not familiar enough with the ADC errata to comment.

    -Lori

     

  • 0 in reply to Lori Heustess
    Intellectual 325 points

    So, if for some reason I ever branched back to BEGIN (without power on reset), I'd expereince locking?

    On 2, I'll make sure to suck-in my memory blocks to be safe.

    Thanks,
    Louis

  • 0 in reply to Louis S
    TI__Guru* 91940 points

    Louis S said:
    So, if for some reason I ever branched back to BEGIN (without power on reset), I'd expereince locking?

    Yes.

    -Lori

  • 0 in reply to Lori Heustess
    Mastermind 7585 points

    Louis,

    if you branch back to BEGIN with an enabled FLASH prefetch pipeline, then you will lock the device (as Lori mentioned). However, you can add some instructions to disable the FLASH prefetch pipeline and some NOPs, before you take your branch back to BEGIN.

    Another option would be to use the Watchdog to cause a RESET instead of  that branch to BEGIN. To do so, just write a false pattern into the WDCHK field of WDCR. The BOOT sequence will then find ity way back into the program.

    Regards

     

  • 0 in reply to Frank Bormann
    Intellectual 325 points

    The power-on reset via watchdog is my current strategy since I'm reluctant to add extra instructions that won't be needed for the TMS release.  For my application, it's no problem.

    I just wanted to make sure I understood why things where working before they had a chance to get me in the back.