We have a custom OMAP-L138 system where a bare metal ARM brings up a SYS/BIOS DSP, and it works, but now I am trying to bring up SYS/BIOS 6.3.33 on the ARM.
I am having trouble controlling power for the DSP from the ARM under SYS/BIOS. I cannot use the PSP, since evidentally it is not built for the ARM (and other posts around here indicate it is not buildable for the ARM), so I am trying to use the same "bare metal" code for bringing up the DSP that I know works in the "bare metal" environment, but I am seeing some significant problems.
More concretely, if I follow the same "wake the DSP code" that works well for the bare metal system, I get the following error when I try to connect to the DSP after I "wake" it,
C674X_0: Error connecting to the target: (Error -1144 @ 0x0) Device core is hung. The debugger attempted to recover debug control, but was unsuccessful. Power-cycle the board. If error persists, confirm configuration and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 5.0.569.0
Lowering TCKL on the emulator settings has no effect.
My DSP start routine is simply,
uint32_T ST4_dsp_Start(void *dsp_start_vector)
{
CSL_PscRegsOvly PSC0 = (CSL_PscRegsOvly)CSL_PSC_0_REGS;
CSL_SyscfgRegsOvly SYSCONFIG = (CSL_SyscfgRegsOvly) CSL_SYSCFG_0_REGS;
ST4_sysconfig_Unlock();
/* force the timer0 clock source to be DSP, since I can't figure out how to do that with .cfg */
SYSCONFIG->SUSPSRC |= CSL_SYSCFG_SUSPSRC_TIMER64P_0SRC_MASK;
// Unlock the system config registers.
CLRBIT(PSC0->MDCTL[CSL_PSC_DSP], CSL_PSC_MDSTAT_LRST_MASK);
// Write the reset vector
SYSCONFIG->HOST1CFG = (uint32_T)dsp_start_vector;
// Power up the DSP
ST4_lpscTransition(PSC0, 1, CSL_PSC_DSP, CSL_PSC_MDCTL_NEXT_ENABLE);
// Release the DSP from reset
SETBIT(PSC0->MDCTL[CSL_PSC_DSP], CSL_PSC_MDSTAT_LRST_MASK);
ST4_sysconfig_Lock();
return (ERR_NO_ERROR);
}
void ST4_lpscTransition(CSL_PscRegsOvly psc, uint32_T in_domain,
uint8_T in_module, uint8_T in_next_state)
{
uint32_T domain_bit;
if (in_domain == 0)
domain_bit = (CSL_PSC_PTCMD_GO0_SET << CSL_PSC_PTCMD_GO0_SHIFT);
else
domain_bit = (CSL_PSC_PTCMD_GO1_SET << CSL_PSC_PTCMD_GO1_SHIFT);
// spin until existing transitions are done.
while (CHKBIT(psc->PTSTAT, domain_bit)) {}
// if we are already in the requested state...just return.
if(CHKBIT(psc->MDSTAT[in_module], CSL_PSC_MDSTAT_STATE_MASK) == in_next_state)
{
return;
}
// setup the transition...clear the bits before setting the next state.
CLRBIT(psc->MDCTL[in_module],
(CSL_PSC_MDCTL_NEXT_SWRSTDISABLE | CSL_PSC_MDCTL_NEXT_SYNCRST | CSL_PSC_MDCTL_NEXT_DISABLE));
SETBIT(psc->MDCTL[in_module], in_next_state);
// kick off the transition.
SETBIT(psc->PTCMD, domain_bit);
// spin until transition is done.
while (CHKBIT(psc->PTSTAT, domain_bit)) {}
while (CHKBIT(psc->MDSTAT[in_module], CSL_PSC_MDSTAT_STATE_MASK) != in_next_state) {}
}
(The bit with the SUSPSRC was an attempt to fix the problem, since it appeared that timer 0 was being claimed by the ARM while in my bare metal system it seems to be assigned to the DSP. I get the same result with or without it, but thought I should leave it in, since it was different than my bare metal. I also reassign the ARM Clock to be timer 2, so rudely putting it back under DSP control shouldn't be a big deal). SETBIT and CLRBIT are obvious routines that work for the bare metal, and ST4_lpscTransition implements the process described in the PSC documentation (again, that works for the bare metal).
To simplify debugging, I also have disabled the MMU on the ARM. Again: same results with MMU enabled and disabled, but I am leaving it this way.
So, any clue as to how to proceed? Am I barking up the wrong tree with booting the DSP this way in the first place (even though it works for the bare metal)? Is there a whole different approach I should take?
