• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 97 subscribers
  • Views 471 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.

DSP OMAP-L137 silicon revisions

E2E_display_name_Mike
Expert 1700 points

Our company  just got a new batch of prototypes and are having some trouble with HPI booting the new boards.  The DSP will boot via JTAG with CCS IDE, but not through the host.  There are very few differences between the boards but one difference is the DSP silicon revision.  The current boards are rev A (1.1) device and the new boards are rev B (2.0) device.  Is there any known issues (or deltas) with this new rev. that would explain this problem?

The PCBs are the same.  The host processor is the same.  Only minor component changes.  When the HPI boot is attempted, the load completes and the code starts executing but halts (or crashes) soon after.  An LED will start to blink and some text will start to come out the UART but then it stops.  This same image can be HPI boot loaded on the original batch of boards we had made.


thanks in advance,

Mike

  • 0
    TI__Guru 62975 points

    Mike,

    Are you performing a read-back-verify operation of the boot image before releasing the DSP to boot?  We have had reports that between Rev A and Rev B devices, there is some latency difference for boot images to land into memory.  Adding a read-back-verify of the last word loaded into memory helped ensure that the entire image landed  in memory before DSP boot.

    -Tommy

  • 0 in reply to tlee
    Expert 1700 points

    Tommy,

    This seems to have fixed our issue - thanks.  Can you clarify or give more details of this issue so we can understand any other differences that may be present?

    The exact fix was done by adding a small delay (~50us) at the end of every sector write (e.g. each memory section).  So doing consecutive writes in auto-increment mode seemed okay, we just needed to pause before changing to a new address and starting auto-increment mode again.

     

    Mike

  • 0 in reply to E2E_display_name_Mike
    TI__Guru 62975 points

    Mike,

    My understanding is that the boot ROM was updated between silicon revs and the cache-invalidate operation was reordered from:

    1. Host completes load of boot image
    2. Boot ROM performs cache-invalidate [boot image has more time to land]
    3. Boot ROM reads parameters configured by host
    4. DSP boots

    to:

    1. Host completes load of boot image
    2. Boot ROM reads parameters configured by host [boot image has less time to land]
    3. Boot ROM performs cache-invalidate
    4. DSP boots

    So Rev 1 allowed extra time for the boot image to land into memory because it performed the cache-invalidate procedure before reading the boot parameters.

    -Tommy

  • 0 in reply to tlee
    Genius 3685 points

    Hi Tommy,

    Thanks for the explanation. One question though: Would it be possible for the boot ROM code to wait for the cache to finish invalidation (You can do this on the ARM-core and I believe that the you can do this on the DSP-core as well, although I admit that I have never digged really deep in this area of the DSP-system)? To me it sounds like kind of an "error" that the user is responsible for adding some kind of "unknown" delay for the invalidation to finish?

    Do you know if there are any plans for changing/fixing this in upcoming ROM revisions?
      Søren

  • 0 in reply to Soren Steen Christensen
    TI__Guru 62975 points

    Soren,

    Unfortunately the ROM code behavior is fixed on silicon.  At this time there are no plans to update the ROM code.

    One can think of the issue as an unhandled race-condition that is exposed when the extra delay introduced by the cache-invalidate procedure is removed.  The safest way to avoid this issue is to read-back-verify the last word written by the host.  When HPI receives the host read request, it will flush the write FIFO before initiating the read instruction so when the data is returned to the host, you can safely assume that the data has landed into memory.

    -Tommy

  • 0 in reply to tlee
    Genius 3685 points

    Hi Tommy,

    Sorry, that my question wasn't 100% clear. I know that the ROM is fixed in silicon and thereby would needa new silicon spin to be changed (which was what I asked if you know would happen in the future - Apparently not). Since you however have a 100% fail proof solution (which I understand why works - read back after write - as opposed to just waiting a random amount of time) I have no problem with the current implementation, although I still would consider it a ROM code error and would recommend you fixing it for future revision/newer chips (just to make it even easier doing HPI booting :-)

    Best regards and thanks for the clarifying - Enjoy your weekend
      Søren