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

L138 emulator debug: DSP jumps to HOST1CFG?

Paul Singh
Expert 2750 points
Other Parts Discussed in Thread: OMAPL138

Hi,

We read http://processors.wiki.ti.com/index.php/Boot_Images_for_OMAP-L138 along with the example code it provides for ARM code to
OMAPL138-ARM-LED said:
1. Set DSP reset vector to the DSP code’s entry point
  /* Set DSP boot address vector to entry point of DSP program
  This must be aligned to 1KB boundaries */
  SYS_REGS->HOST1CFG = 0x80010000;
2. The ARM core then wakes up DSP:
  /* Wake up the DSP */
  CSL_FINST(psc0Regs->MDCTL[CSL_PSC_DSP], PSC_MDCTL_NEXT, ENABLE);
  CSL_FINST(psc0Regs->PTCMD, PSC_PTCMD_GO1, SET);
  while(CSL_FEXT(psc0Regs->PTSTAT, PSC_PTSTAT_GOSTAT1)==CSL_PSC_PTSTAT_GOSTAT1_IN_TRANSITION);
  CSL_FINST(psc0Regs->MDCTL[CSL_PSC_DSP], PSC_MDCTL_LRST, DEASSERT);
 
So the DSP starts executing its program under the auspice of ARM.
 
The above example is good if the device is going to be booted by AIS. On the other hand when debugging code and when we need to test ARM’s 1) setting DSP vector 2) waking DSP up, there comes a problem: we first have to load DSP code into the memory. To load DSP .out file we need to first wake up DSP, then connecting to the DSP core. But after having loaded .out file into the DSP core, the DSP’s PC (program counter) would already be set to the entry point of the DSP program, so it basically mean we have no chance to let ARM core do the HOST1CFG setting + wake DSP job. If we simply turn off the PSC of DSP, change HOST1CFG, and wakes DSP up again, DSP would not jump to the address contained in HSOT1CFG but would stay at where is stopped before last PSC off.
So it seems that the only way to let ARM do the “full job” (set HOST1CFG + wake DSP) is by using it in the AIS boot mode (because in AIS boot we don’t need to wake DSP first before loading DSP code), not in debugging mode?
 
 
Paul
  • 0
    TI__Guru** 116170 points

    Paul,

    In general, you seem to have got the correct idea of running code on C674x DSP from the ARM on the OMAPL138 device but I don`t quite agree with your thoughts of not being able to use the DSP wakeup and run sequence in non-AIS environment. For ARM+DSP code development, we provide a software link between the two processor which is called DSPLINK or SYSLINK(next gen DSPLINK). If you look at the Proc Manager modules in DSPLINK or SYSLINK , you will notice that they provide a COFF and ELF loader that runs on the ARM which is used to parse the DSP executable and load the sections of the DSP binary in appropriate memory locations. After the code is loaded the SYSLINK wakes up the DSP, much in the same way as is shown in the secondary bootloader(ARM UBL) and sets the entry point using HOST1CFG.

    http://processors.wiki.ti.com/index.php/SysLink_UserGuide#Processor_Manager

    For a detailed HelloDSP example on DSPLINK, refer to this wiki,(The example is on OMAPL137 but it should give you an idea of how it works)

    http://processors.wiki.ti.com/index.php/Example_application_using_DSP_Link_on_OMAPL1x

    Hope this helps. Let us know if you have any follow up questions.

    Regards,

    Rahul


    http://processors.wiki.ti.com/index.php/SysLink_UserGuide#Processor_Manager

  • 0 in reply to Rahul Prabhu
    Expert 2750 points

    Rahul,

    If I am running raw code on both cores (without Linux, BIOS, etc.), can I still take any advantage of the DSPLINK/SYSLINK? This environment is very limited can cannot execute commands like malloc() which requires an OS to maintain the memory pool. Does DSPLINK/SYSLINK need these services (malloc and other OS layer services)?

     

    Paul

  • 0 in reply to Paul Singh
    TI__Guru** 116170 points

    Paul,

    No, if you are running raw code on both cores, DSPLINK/SYLINK cannot be used as it requires BIOS to run on the DSP and some high level OS like linux, winCE ..etc to run on the ARM. For raw code, you could potentially look at an IPClite implementation code provided in Starterware but its doesn`t integrate the ELF/COFF DSP loader glue in the setup so you would have to integrate this part yourself.

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    Expert 2750 points

    Rahul,

    I will look into the IPCLite, thanks for suggestion.

    Paul