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.

How to implement reset logic on the OMAP-L138 DSP core?

Other Parts Discussed in Thread: OMAP-L138, TPS3125, OMAPL138

Hi

I am designing reset logic to the DSP core on OMAP-L138 SoC such that it can perform reset to load application from NAND flash. This is to be able to remote update DSP software. 

I am thinking to use one of the GPIO pin of DSP to assert reset by connecting the GPIO to RESET pin of the OMAP-L138 SoC. Is this good idea? 

  • Hi Mitesh,

    I've forwarded this to the hardware design experts. Their feedback should be posted here.

    BR
    Tsvetolin Shulev
  • Hi,
    Any update on this please. ?
  • Hi Mitesh,

    Asserting RESET without simultaneously asserting TRST will incur a warm reset, not a POR (power on reset) - is that what you want? Refer to 6.4.2 Warm Reset of the datasheet.

    A warm reset provides a limited reset to the device. Warm Reset is initiated by bringing only RESET low (TRST is maintained high through a warm reset). Warm reset sets certain portions of the device to their default state while leaving others unaltered. All pins are tri-stated with the exception of RESETOUT
    - internal memory is preserved
    - boot pins will be not be latched when RESET goes high, but instead retain the same values from the last POR.

    To ensure you do a POR, you can keep TRST low always (until you want to use JTAG) - TRST only needs to be released when it is necessary to use a JTAG controller.

    Do you mind if the ARM core also reboots? If not, then applying reset to reboot form NAND may be a viable option, but you may need to use more than a GPIO to drive RESET and TRST both low...

    According to Table 6-1. Reset Timing Requirements, the pulse width of RESET needs to last at least 100ns. If you simply connect a GPIO to RESET, that GPIO will go Hi-Z in RESET, and it may not be able to satisfy this requirement. If you add a pull-down resistor to the Hi-Z GPIO, then it will never release reset to the device - it will always be pulled down... You could use the GPIO (with a pull-up) to trigger a reset pulse circuit like the one below. The capacitor ensures the reset pulse will last a certain duration.

    You could also use a Voltage Supervisor with Manual Reset like TPS3125. There is an internal timer which keeps RESET low for a specified delay time.

    A watchdog reset triggers a POR - maybe you can exploit that to achieve your goal: Force the watchdog timer to expire and reset that way.

    Consider also the boot mode pins - are they statically pulled high or low? Are they the same during normal operation and during firmware upgrade? They also have requirements specified in Table 6-1. Reset Timing Requirements of the datasheet. 20ns setup before reset rising edge and 20ns hold after reset rising edge. If they are statically tied with pull-ups and pull-downs, then that will easily be satisfied. Do not use GPIOs by themselves to drive the bootmodes since GPIOs will go Hi-Z.

    It sounds like you only want to reset the DSP core and load some new code into the DSP core only (with the ARM core still running). I believe there is a way to do this with the shared memory, and powering-down the C674x megamodule. I can loop in someone more knowledgeable if this is of interest to you...

    The following software sequence is required to power-down the C674x megamodule:

    1. Enable power-down by setting the MEGPD field in the PDCCMD register to 1.

    2. Enable the CPU interrupt(s) that you want to wake the megamodule up; disable all others.

    3. Execute an IDLE instruction.

    The megamodule stays in powered-down mode until the interrupts enabled in step 2 above are awakened

    Refer to the following wiki pages:

    http://processors.wiki.ti.com/index.php/OMAP-L138_Bootloader

    http://processors.wiki.ti.com/index.php/Boot_Images_for_OMAP-L138#Booting_DSP_Binaries

    Hope this helps,
    Mark

  • Hi Mark, sorry of the late reply but thanks a lot for your reply. This is useful.

    All I am trying to do is:

    Would like a DSP reset feature from ARM (Linux), We want to use this as a remote upgrade restart. The boot pins are static and are generally set to boot DSP from NAND flash. The TRSTn is connected to GND via Pull down resistor.  The idea is Linux would write to the DSP NAND Flash the new DSP app and then on next reboot DSP should use the latest DSP app. 

    It sounds like the last point you made about "a way to do this with the shared memory, and powering-down the C674x megamodule" is this possible to be done in Linux? Is there any example app for this? 

    Thanks. 

  • Hi Mitesh
    I have been monitoring this thread and while I still don't completely understand the intended use-case (sorry - i know you have tried to articulate this) , i want to point a few specifics

    1) There is no way to do a "chip" reset that will have different behavior on the SoC cores i.e. ARM and DSP , if you do any sort of chip reset it will impact both ARM and DSP cores and the rest of the chip logic. The definition of power on reset and warm reset is provided in the datasheet section 6.4 and it explains what all logic is reset by these resets etc.
    2) On OMAPL138 , ARM is the "boot master", ie. if the chip is reset (depending on the type of reset) , ARM RBL will kick in and you will essentially go through the whole boot process, where somewhere in your secondary boot loader/ uboot you would need ARM to enable the DSP and have the relevant code re-loaded
    3) It almost appears like you don't want to disturb the entire chip state except just "DSP" core getting a new image from NAND flash? In general this maybe more software than using any chip reset etc - you could potentially do this using the PSC controller, where ARM can write to the DSP PSC control registers MDCTL15 to do a local reset etc.
    4) Most commonly from a system integration perspective only 1 core does the flash/file system management as the various file system maybe more easily manageable by either ARM or DSP and not both? processors.wiki.ti.com/.../Filesystem_in_NOR_or_NAND

    I am not aware of complete end to end example for the use-case you are asking for.

    DSP reset management by something like IPC layer , should be available in linux- if this is something you are interested to explore further, I can point this thread to one of my software colleagues, to see if you can point you relevant links/software examples around this.

    Hope this helps some.
    Regards
    Mukul
  • Hi Mukul,

    From Mark's reply, it was clear and sensible to use the DSP PSC to reset DSP core from Linux. I am still trying to get Linux using SDK4.0.0.4 running on the custom board and one I get that working would like to try the IPC method of rebooting DSP. I was trying to read about the remote-proc in the Linux, that  as well sounded like the think would be use in the process of loading DSP FW. But yes, thanks for your reply. I have decided not to do any hardware mods to just get the reset. Would do it from Linux using the DSP PSC logic. Cheers.

  • Hi Mitesh
    Thanks for the clarification. Looks like you are headed in the right direction. If you have follow up question on remote-proc / IPC , please do open a new thread.
    Regards
    Mukul