We are using the Integra chip and do not want to use Syslink to download the DSP from the ARM. We are trying to write our own downloader routine. We are doing the following procedure:
1. Placing the DSP in reset
WR_MEM_32 (RM_ACTIVE_RSTCTRL, 3)
2. Downloading the DSP
3. Setting the DSPBOOTADDRESS value to the starting address in DDR3 memory
4. Removing the DSP from its reset condition
WR_MEM_32 (RM_ACTIVE_RSTCTRL, 1); WR_MEM_32(RM_ACTIVE_RSTCTRL, 0);
When we exercise this procedure the values in the RM_ACTIVE_RSTST register do not change and update as detailed in the TI sprugx9.pdf (Technical Reference Manual)
Also. the DSP appears to successfully download but will only run correctly if I step through the procedure in my ARM debugger. If the ARM is allowed to run without interruption by the debugger, the DSP does not boot correctly.
Our questions are:
1. Is there a better documented procedure for downloading and booting the DSP from the ARM without using SYSLINK?
2. What interaction is my dubugger having such that stepping through the procedure works and running full out (even with delays in-line) does not work?
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:
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
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
If you think this post answers your question, please mark it with the Verify Answer button.
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.
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?
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)
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.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.