[quote user="ReinierC"]
I was in fact wrong here, I had assumed it was a UTL_halt() call, where it is in fact a run-into-the-weeds case. The main() function would finish executing and in the process of starting all the various DSP/BIOS modules, it would just end up at some seemingly random address (0x7F7FF0). In particular, this would happen during a call to TSK_startup in the generated *.s62 source file. Maybe its an exception of sorts?
[/quote]
Address 0x7f7ff0 is in the L2 ROM, and is likely the SK code. It might be the "SK_ns_wedge" function which parks the CPU in an inifinite loop when SK detects something wrong.
Can you determine with more precision exactly what operation is making it "jump into the weeds"? It's either a badly formed SK syscall, or accessing something that it can't access which is causing an exception. The OMAP-L138 was one of the last processors to get SK support in DSP/BIOS, and it's possible that something was missed.
[quote user="ReinierC"]In parallel to this, I also created a similar non-DSP/BIOS application and I saw the exact same behavior in SECUREWITHSK mode, the moment the interrupt vector table (ISTP register) was set, i.e. I also ended up at address 0x7F7FF0[/quote]
Since ISTP is a secure-access-only register, it makes sense that you'd end up in this bad place. DSP/BIOS, in the SK mode, calls into SK to register for interrupt processing (and exception processing) and doesn't write the ISTP register (in normal, non-SK mode DSP/BIOS writes directly to the ISTP). Your non-DSP/BIOS application could conceivably call the same SK syscalls that DSP/BIOS does (the ones in sk_cwrap.asm). It would want to *not* write the ISTP nor try to write into the vector table pointed to by ISTP (which it can't even see), but instead just make calls into SK_registerOSIntr().
There are many things that an app can't do when running in the SK mode that it normally could (and would) do, hence the existence of the SK syscalls.
Regards,
- Rob