HOW TO WAKEUP 138 DSP without dsplink/c6run

I've resolved the question1, its a software bug

And what about the other questions?

Please see this post, http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/78767/283058.aspx#283058.  Even though it is not exactly like your application, it will still apply on how to create one boot image from two .out files.

liangzhu ma said:

2.  How to complile a DSP program, Use CCS?  Do I need to convert the out file to bin file? How to?

You'll need to compile and create the DSP program using CCS.  The post I link above will give you instructions on how to create one boot image from two .out files.

liangzhu ma said:

3. Can I let dsp run in its inner ram, not DDR? Edit the CCS cmd file?

Yes, you can run DSP from its internal RAM.  You will need to change the cmd file to allocate the data and program to the inner ram. 

--Christina

Thank you very much Chirisina,

I've still some questions.

My system is   UBL + uboot + linux, ， UBL is generated by AIS tool

Do you mean I've to let UBL, DSP.out, arm.out to be a single AIS file?

When you use AIS to generate the UBL, you can also provide the dsp.out to the AIS tool.

Above is an example on how to do it.   Any files that you add to the AIS tool with an @ symbol, will be loaded to the specified memory location.   Therefore, you can load multiple programs from one generated bin file.

--Christina

Hi, liangzhu ma

I've also run into the same problem as you did, the question 1.

Could you kindly tell me how do you resolve the problem that PSC0.MDSTAT15 not changing to 3h.

Thank you!

--William

I am the workmate of liangzhu Ma.

Now we add this  DSP_Wake_Up() into the UBL, and generate the .bin file by arm.out and the DSP.out.

void DSP_Wake_Up()
{
    DEBUG_printString("\r\n wakeup DSP running");

 SYSTEM->HOSTCFG[1]=0x80010000;
 while ( ((PSC0->PTSTAT) & (0x00000002))!=0 );//GOSTAT[1]
 PSC0->MDCTL[15] = ((PSC0->MDCTL[15]) & (0xFFFFFFE0)) | (PSC_ENABLE);
 PSC0->PTCMD |= (0x00000002);//GO[1]
 while ( ((PSC0->PTSTAT) & (0x00000002))!=0 );//GOSTAT[1]
 while (((PSC0->MDSTAT[15]) & 0x1F) != PSC_ENABLE);

 DEBUG_printString("\r\n wakeup DSP finished");    
}

and in the cmd file of DSP, I set all the SECTIONS to the address that started from 0x80010000.

I see the dsp.out file are successfully loaded to 0x80010000. But the DSP still not wake up.

In the DSP code I change the value of the Shared RAM Memory, but when I read them after run DSP_Wake_Up(), I didn't get the changed value.

I also do the wakeup follow the 13.2 in system reference guide, but failed too. Is there still something wrong with the wakeup steps?

After looking at Section 13.2, I realized that I forgot to mention that LRST bit needs to be set to 1 to de-assert the DSP local reset.  If that bit is still set to 0, the DSP will be in reset and will not execute code, even though it is powered up. 

Can you confirm if PSC0.MDSTAT15 is 0x103 (Enabled and De-asserted local reset) after the function DSP_Wake_Up() gets called?

--Christina

After DSP_Wake_Up() the PSC0.MDSTAT15  is 0x1d03. Is that right? 

When UBL run, I find that the DSP L2 RAM can't be recognized. So even the DSP can be wakeup by this way, I still can't set the DSP code run in it's local L2 RAM (which is started with 0x11800000),isn't it?

Zhang Yanhui 

These are the PSC0.MDSTAT15 values I got when I ran it on my board.

After device boot:  0x0000A00
After DSP PSC enable:  0x00001E03
After deasserting DSP local reset:  0x00001D03

The value you are seeing is correct.

yanhui zhang said:

When UBL run, I find that the DSP L2 RAM can't be recognized. So even the DSP can be wakeup by this way, I still can't set the DSP code run in it's local L2 RAM (which is started with 0x11800000),isn't it?

Your understanding is correct.  DSP L2 RAM can only be accessed when the DSP is powered up via PSC.  If you want to load code into L2 for the DSP to execute, use the following steps

• Enable DSP via PSC without deasserting the DSP local reset
• Load the program into L2 through the ARM.  During this time, you should not be able to connect to the DSP through CCS because the DSP is still in reset.
• After loading the program into L2, de-assert the DSP local reset
• The DSP will jump to the value defined in HOST1CFG and start executing

After the file gets loaded (either their AIS or CCS), make sure the entrypoint is the same as the value in HOST1CFG

• If the entrypoint is not the same (even by a few bytes), it might cause the DSP to execute some illegal instructions which might prevent the program from running correctly.
• One way to test is...
  • Load your DSP program
  • Connect to the DSP through CCS
  • Set your Program Counter to the same address as defined in HOST1CFG
  • Run the program
• If you program does not run correctly, there is an issue with how the program got loaded or compiled.

--Christina

Hi Christina,

clam said:

When you use AIS to generate the UBL, you can also provide the dsp.out to the AIS tool.

Above is an example on how to do it.   Any files that you add to the AIS tool with an @ symbol, will be loaded to the specified memory location.   Therefore, you can load multiple programs from one generated bin file.

Could you please give a small clarification?

a) Does it work as well with two .out files (1 for ARM and 1 for DSP) without providing an address?
In my case I just have the following: C:\armboot.out;c:\dapboot.out.

b)  I would guess that the AIS tool should be able to extract the info (like the run address) from the DSP .out file directly so that the ARM ROM bootoader can load the DSP application the same way it loads it's own application. Correct? Am I missing something?

My DSP application is located in L2SRAM (0x1180 0000). After the DSP is out of reset I can connect with CCS but I do not see the application being loaded at this address.

When using CCS to load the ARM and DSP application everything is working fine. It jumps to  0x1180 0000 where the vector table is located.

c) is it possible at all to use the AIS with with two .out files (1 for ARM and 1 for DSP) and expect the ARM to load the DSP sections? Or do I need a 2nd level bootloader in my ARM application that will copy the different sections from Flash to RAM?

Thanks and best regards,

Anthony

Little update as it is working now.

- Used the SharedRam as the DSP application can not be loaded by the ARM ROM botloader in L2SRAM as at this point of time the DSP is still not enabled!

- The AIS utility is able to handle two .out files (1 for ARM and 1 for DSP) without providing any address.