• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 100 subscribers
  • Views 731 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.

Core Local Reset: what happens?

Joel Keller
Expert 1305 points

Hi,

The PSC (Power Sleep Controller) user's guide states: 

<<<

In addition to module reset described in the previous section, the C66x core can be reset
using a special local reset. When local reset is asserted, the internal memories (L1P,
L1D, and L2) for the core are still accessible. The local reset resets only the
corresponding C66x core, not the rest of the chip. Local reset is intended to be used by
the watchdog timers to reset the C66x core in the event of an error. The procedures for
asserting and de-asserting local reset are as follows (Y denotes the module domain
number):
1. Set MDCTL[Y].LRSTZ to 0x0 to assert local reset.
2. Set MDCTL[Y].LRSTZ to 0x1 to de-assert local reset. The C66x core
immediately executes program instructions after reset is de-asserted. Note that
the boot sequence does not re-occur unless there is a device-level reset. Execution
of code previously in L2 begins execution.

>>

What does "Note that the boot sequence does not re-occur unless there is a device-level reset. Execution
of code previously in L2 begins execution."  mean *exactly*?  Specifically does this mean that nothing in the boot ROM code is run at all?  What specific instruction or address does execution start at in L2?  Surely the core's registers are reset...

Thanks, 

Joel

  • 0
    TI__Genius 9915 points

    Yes the boot ROM code is not executed. The execution address should be stored by the application in DSP_BOOT_ADDRESS. You can populate that address way ahead in your application and it is preserved during reset.

    Thanks,

    Arun.

  • 0 in reply to ArunMani
    Expert 1305 points

    Thanks to your hint Arun, I believe I now understand.  It seems that the DSP cores do indeed jump to the address in DSP_BOOT_ADDRx when brought out of local reset...however, it appears that by default, these registers contain the address 0x20B00001 (I'm not sure what the last bit is doing here...), which is the start of the boot ROM code.  This means that if you naively do a 'local reset', the boot ROM code does indeed run again.

    This confused me, as no where in the documentation I have does it mention these registers when talking about 'local reset'.  In fact, searching for "DSP_BOOT_ADDR" in the device datasheet, you'll see that these registers are completely undocumented (the only place they show up is in name only in the global memory map section).   They are also unmentioned in the PSC userguide, and the bootloader userguide, as well as every other place I looked.

    Arun, can you confirm that my new understanding is correct?   Also, if you have a means of providing feedback for the DSP documentation - I believe that the DSP_BOOT_ADDRx registers are undocumented, and that the documentation surrounding 'local reset' is inadequate.


    Thanks very much for your help.

    -Joel

  • 0 in reply to Joel Keller
    Prodigy 110 points

    Thanks for hints, Arun and Joel. 

    Joel, your last post really clarified this issue for me. Note also that rumors have it that the actual boot address has to be 0x400 aligned. I can not recall to have read this in any documentation from TI whatsoever, but it is mentioned in this thread: http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/p/230881/813161.aspx

    From what you write, it seems that the boot sequence that TI has documented, involving the ROM bootloader, and generating an inter core interrupt to wake that boot loader up from the IDLE instruction only works after POR, where actually DSP_BOOT_ADDRx is the default 0x20B00001 and the cores are executing the ROM bootloader. Also, to load a NEW image on a core (after having run another image), the procedure will be as follows:

    1. Put the core into local reset by asserting the LRST bit in MDCTLx
    2. Wait for local reset to finish by polling status of MRSTDONE and LRSTDONE bits in MDSTATx
    3. Write a 0x400 aligned boot entry address into the DSP_BOOT_ADDRx location
    4. Release core local reset by deasserting LRST bit in MDCTLx
    5. The core should now boot

    Arun, can you confirm these points? It would also be very nice to get all this info into the bootloader documentation for others to read as well. 

    Something else that confuses me is the RESETISO bit in the MDCTLx registers, and the RSISO register in the PLL controller. Are these bits/registers at all relevant for doing a local reset of a core, or should they just be left alone?

    And - should also the module be left in the "0x3 Enable" state (not setting MDCTLx NEXT field to 0x0 SwRstDisable)? What is the default module state for a corepack after POR? I assume it is enabled, as they seem to boot without intervention (can not find info about default state in the documentation).


    Thank you very much in advance.

    - Oyvind

  • 0 in reply to OyvindV
    Expert 2145 points

    Hi Oyvind,

    Did you get any replies to your questions in this post? I am also working on using local reset.

    Out of interest, where did you find the procedure which you list above, specifically step 2 "Wait for local reset to finish by polling status of MRSTDONE and LRSTDONE bits in MDSTATx"?

    Have you had any issues writing multiple times to DSP_BOOT_ADDRx from a remote device (if that is indeed what you are doing)?

    Thanks for your help,
    Geraldine