MCSDK Version: 2.1.2.6
Compiler Version: 7.4.1
While developing an SRIO messaging application, it was observed that the application runs to completion successfully after a board power up. However, after performing a "CPU reset" on Core 0 (all other cores are idle) via the emulator and reloading/rerunning the application, Tx errors are observed (specifically, descriptors are pushed to the the Garbage TOUT queue). However, if a System Reset is performed, followed by an OPTIONAL run of the GEL script (evmc6670l.gel) included in the MCSDK, all is fine and the software will again run to completion. I am currently unsure if the reset problem resides in the SRIO peripheral or the multicore navigator.
SRIO messaging makes use of the Multicore Navigator, which does not appear to have a reset register. Based on other forum postings, a software approach is needed to get the Multicore Navigator in a reset state.
http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/261743.aspx
http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/247150.aspx
In the second post (second entry), it was suggested:
"1) cycling the clock+power domains of your peripherals - this will be similar to what is done on a SOC reset, and 2) reset the queue manager by clearing the memory regions and pushing a NULL pointer on each queue (this should destroy the descriptors of each queue)."
It is believed that the SRIO peripheral is being put into a reset state by cycling power to the module through the power sleep controller (SRIO CPPI DMA Tx registers at 0x0290_1400 appear to get cleared in this process).
The second item, the multicore navigator, was satisfied with the following reset function:
// reset the queue manager by clearing the memory regions and pushing a NULL
// pointer on each queue (this should destroy the descriptors of each queue).
void ReinitializeQmssDevice()
{
uint32 u32MemoryRegion;
uint32 u32QueueNum;
uint16 u16Count;
CSL_Qm_descriptor_region_configRegs *poConfigReg = (CSL_Qm_descriptor_region_configRegs *)CSL_QM_SS_CFG_DESCRIPTION_REGS;
// Zero out the memory regions. The C6670 has 20 separate memory regions for descriptor sets.
for(u32MemoryRegion = 0; u32MemoryRegion < 20; u32MemoryRegion++)
{
poConfigReg->MEMORY_REGION_BASE_ADDRESS_GROUP[u32MemoryRegion].MEMORY_REGION_BASE_ADDRESS_REG = 0;
poConfigReg->MEMORY_REGION_BASE_ADDRESS_GROUP[u32MemoryRegion].MEMORY_REGION_DESCRIPTOR_SETUP_REG = 0;
poConfigReg->MEMORY_REGION_BASE_ADDRESS_GROUP[u32MemoryRegion].MEMORY_REGION_START_INDEX_REG = 0;
}
// Push a NULL pointer on each queue. This will loop through all the queues
// and ensure each is in an empty state. The Qmss_queueEmpty() will write a
// NULL pointer to the Queue Register D.
for(u32QueueNum = 0; u32QueueNum < 8192; u32QueueNum++)
{
u16Count = Qmss_getQueueEntryCount(u32QueueNum);
if(u16Count)
{
Qmss_queueEmpty((Qmss_QueueHnd) u32QueueNum);
}
}
}
Even with this approach, it still appears that my SRIO messaging application does not restart properly and descriptors pushed onto the SRIO Tx queue are recycled to the garbage queues (TOUT). I have consulted with the SRIO_LoopbackTestProject, which is distributed in the MCSDK, and tested on a C6670EVM and have encountered the same problem of "software restartability." However, in this project, I didn't observe any descriptors being pushed onto garbage queues.
QUESTIONS:
1) My overall question is what additional steps do I need to take to get my software to properly reset peripherals (Multicore Navigator, SRIO) without a full System Reset?
2) The first link above referenced an upcoming fix to address restartability of QMSS/CPPI. I am assuming this would be inside the low level drivers distributed in the MCSDK and get rolled in the next release? Is there a projected release date with these fixes?
