Downloading Integra C674x DSP from the ARM without using Syslink

Hi,

Even though you don't want to use SysLink for downloading the DSP, it might be a good idea to refer to the relevant SysLink code to get the full sequence. The code you would need is in:

packages\ti\syslink\family\common\ti81xx\ti81xxdsp

A few questions:

1. Have you ensured that the DSP is powered up? Refer to file packages\ti\syslink\family\common\ti81xx\ti81xxdsp\Dm8168DspPwr.c

Function DM8168DSPPWR_on

2. Have you ensured that your DSP boot address is aligned to 0x400? By default, the _c_int00, which is the entry point, is not aligned to 0x400. You need to explicitly align it to 0x400. This can be done by adding the following in your DSP linker command file (for elf file): -eti_sysbios_family_c64p_Hwi0

Regards,
Mugdha

Mugdha,

Thanks for the response. I have looked at the Pwr On routine that you referenced. It appears that we are doing the same thing. We are setting the DSPMEMSLEEP register to 0, enabling the clocks, setting the RM_ACTIVE_RSTCTRL register to 1, downloading the DSP successfully, setting the Boot Address and then setting the RM_ACTIVE_RSTCTRL register to a 0.

The DSP boot address is being set to 0x83007400.

It works just fine if I sterp through the code using CCSv5, however when the code is allowed to run without interruption, the DSP code does not start.

Rick

Rick,

When you say that the DSP does not boot correctly or does not start, what exactly happens? Are you not able to connect using CCS because the DSP is still in reset? Or does something else happen?

Since we have not seen such an issue before, just throwing a few questions out there ... hoping one of them might click.

Is your DSP MMU in bypass?

What is the definition of your macro: WR_MEM_32? Does it use typecast to (volatile UInt32 *) to make sure no compiler optimizations are kicking in?

Are you also enabling GPTIMER3 (which is used by BIOS on DSP - btw, are you using BIOS on the DSP)?

Can you check your CCS GEL files to make sure they're not doing any unexpected initialization that could conflict with what you're doing in your code?

What is your OS on the ARM? Have you ensured that the MMRs are not falling into cached space on the ARM?

Regards,

Mugdha

Mugdha,

We are using vxWorks as our ARM operting System. I have created a simple program using CCSv5 that toggles a GPIO line on the Integra. It is not a SysBios project. I have taken the output file from CCS and converted it to a Intel formatted hex file using the tools provided with CCS. I start vxWorks Workbench and connect to the Integra ARM, load my ARM side code which is only supposed to download the DSP and get it running so that I can check the GPIO line to verify that the DSP was successfully loaded and releases from reset. When I step through the ARM code, I see the GPIO line being toggled. When I run the ARM code with no interruptions, the GPIO is in a steady state high position. In this condition, I have started CCS and connected to the DSP. The status in the debugger window says that the DSP is Running.

How would I know if the DSP MMU is in bypass or not and why would it be different by stepping through the ARM code as opposed to running it without interruption?

Our WR_MEM_32 is defined as:

#define WR_MEM_32(addr, data)    *(unsigned int*)(addr) =(unsigned int)(data)

Thanks

RIck

Rick,

I just want to hear if you solved your DSP boot without debugger attached? I have been asked a similar question recently so I am keen to know.

Thanks.

/Magnus