Hi,
I encountered main loop halting inside SDRAM functions when ISR is leaving less than certain time interval for main loop execution.
The Setup: TMS320C6727 DSP with SDRAM Program built with CCS v3.3 Main loop (code section at internal RAM) with event-driven function calls (code section at SDRAM) ISR at constant frequency 16kHz
Test Conditions: The ISR processing is increased so that ~4us interval is left for main loop processing Before event happens, the main loop is still running (The unexpected behavior) When event happens, the main loop halts forever Interrupt Return Pointer (IRP) does not change at all. It indicates that the main loop halts in SDRAM function (by looking up the value in map file) (Tried several times) I stepped out of the SDRAM function back to internal RAM function using emulator and let it free-run. But main loop halts again in another SDRAM function The ISR processing is then reduced so that more than ~4us interval is left for main loop processing Main loop processing then resumes
Questions: When leaving less than certain time interval for main loop processing, why running the main loop internal-RAM function is ok but running the main loop SDRAM function causes the main loop to halt forever? (is it related to instruction fetch behavior?) How to setup the device to ensure the main loop will not halt forever under frequent and short main loop execution interval like above?
Greetings,
Considering the C6727 architecture, if the Program Cache is disabled, then an application residing in external SDRAM will run a lot slower than in IRAM, and for that you need to ascertain that your Program Cache is enabled, then your SDRAM resident code will improve in performance.
Next put some small Interrupt Threshold on the module that contain your main loop as well as any TI library linked in and used in your main loop.
All this assume your SDRAM EMIF setup is correct and match your choice device.
Good Luck,
Sam
I tested that enabling instruction cache works (not tried further changing interrupt threshold value). Thank you very much.
Can you further explain how instruction cache helps the program halt situation? Also why program halts without instruction cache enabled?
Enabling the Program Cache aided your runtime to speed up enough your ISR and rectified the background loop process starvation on CPU cycle.
I still cannot get how it works. So why background loop halts in SDRAM instruction if instruction cache is not enabled? (is it because if interrupt arrives at the middle of instruction execution, CPU will discard the instruction execution and serve the ISR? How to modify the behavior so that interrupts will not cause the CPU to discard the current instruction execution, assuming no disable interrupt?)
Your use of "CPU Halt" when the error condition occur is too little details. Aside from the error being remedied by enabling the Program Cache, go ahead and dis-able it, reproduce the error condition, then examine the following during the error
1. Call Stack.
2. Interrupt Enable.
3. Local variables involved in your main background loop.
4. May be data arrays used.
5. SDRAM interface.
6. Then when you are at such condition, attempt to singlw step the CPU and see what instructions are being fetched and from where.
Doing the above may aid in explaining what happened when the ISR made the background freeze.
Typically in such a run-time where ISRs are used in foreground and library functions are used in background, you will need to build with certain interrupt threshold to make the run-time work properly. Having the Cache disabled surfaced the race condition that exhibit itself in no more ISR and the CPU is frozen.