Where can I find source code for _tmk_SwitchContext_Runtime function?
Where can I find informations for TMK library?
My application generates EXCPT 0x0 inside _tmk_SwitchContext_Runtime() and I don't know why
The TMK library is an internal library which contains the core of VDK and its contents are not in the release so you will not be able to find them.
Do you have any problems which relate to it? Exception 0 is normal in VDK projects as VDK uses for its internal functioning. Quoting from the VDK manual:
"VDK reserves user exception 0 (EXCPT 0) for internal use.
The IDDE automatically adds a source file to all VDK projects for Blackfin processors. The source file contains template code for a user exception handler and defines an entry point for any service or error exceptions you wish to trap. When an exception occurs, VDK intercepts the exception. If it is not the VDK exception, VDK will try to determine whether the exception is a CPLB miss, in which case cplb_hdr will be invoked. If VDK cannot identify the exception as either VDK or a CPLB miss, then the user exception handler executes.
The VDK User Exception handler does not return from jumps to either UserExceptionHandler or cplb_hdr, so short jumps must be used to avoid potential corruption of the P1 register. Because of this, the LDF must set the sections L1_code and cplb_code close in memory to avoid link errors"
Hope this helps
Do you have any problems which relate to it? Exception 0 is normal in VDK projects as VDK uses for its internal functioning.
Yes, I have a problem.
The last 2 instruction of _tmk_SwitchContext_Runtime( ) functions are
EXCPT 0x0 ;
JUMP.S 0 /*0xFFA00DDA*/ ;
so my program hangs in the "jump 0" instructions.
The timers and the interrupts are working properly, but the thread switching doesn't work.
That JUMP.S 0; instruction should never be reached. You'll notice that the instruction immediately before it is EXCPT 0; which will divert execution to the exception handler. The exception hander should (and must) never return to this point.
This code sequence is used when VDK is context-switching from one thread, which is yielding execution via an API call, to another which was previously pre-empted by an interrupt. The sequence is necessary in order to return to the interrupted thread with its complete register set restored. The contents of the RETX register - which will be the address of the JUMP 0; - are replaced by the interrupted execution address of the destination thread.
The most common reason for execution reaching the JUMP 0; instruction is that the VDK exception handler has been replaced with a different handler, which is failing to handle the EXCPT 0 exception and is incorrectly returning to the RETX address. Could this be what is happening in your case?
If this is not the cause of your problem then I believe this issue will require some debugging and analysis of your code, and would therefore be better handled by the private support channel. Please use the Support Form (link below), to contact us. Please also include a link to this forum discussion. http://www.analog.com/processors/support
If appropriate, the outcome will be posted here.
thanks for your help.
It's clear from your answer that you know very well how the VDK works, so I think you can help me solving my problem.
I sent a request through private support channel, and I hope I'll hear you ASAP via email.
We managed to resolve this issue via private support. There were a few things that we had to take into account.
- On VDK projects the VDK exception handler should not be replaced with your own. VDK raises exception 0 in its normal path and this is not an issue. VDK also passes cplb misses to the runtime library so they are handled. Any other exceptions are passed to the application and can be handled in UserExceptionHandler which is in all VDK applications.
- When a thread stack overflows the thread structure can get corrupted because they are allocated contiguosly in memory. This could create many different problems includiing misaligned accesses like was happening in this case. If a thread template displays as ???? in the VDK Status window then it is very likely that the thread has been corrupted. If so the thread stack should be the first thing to consider.
- There is an anomaly in VDK which means that if more than one CreateThreadEx calls use the same structure as an argument all fields should be reset between calls (even if they were originally set to 0).
Retrieving data ...