TC233 - Unhandled Excpetion: Class 3 Tin 6

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Level 1
Level 1
First reply posted 5 sign-ins First like given

Hello to everyone,

and thanks for you reply.

I have a problem with the handling of interrupt. Sometimes It appens a trap Class 3 (context management) TIN6.

From the TC2xx architecture I Have:

CTYP - Context Type (TIN 6)
Raised when a context restore operation is attempted but the context type, as indicated
by the PCXI.UL bit, is incorrect for the type of restore attempted; i.e. a restore lower
context is attempted when PCXI.UL == 1, or a restore upper context is attempted when
PCXI.UL == 0. As with the CSU trap, this indicates a system software error in context list

Which Is the best way to prevent this kind of trap?

To reply this error, I debugged my code putting a break inside an interrupt and I changed manually the PCXI register,  in particulare the flag "Upper or Lower context Tag". It seems like somewhere in the code this register changes the PCXI register and the os can't restore the old context.


Any Idea?


2 Replies
250 replies posted 100 solutions authored 25 likes received


Please check the section 2.11 Context Related Instructions in the below where I'm referring few things in my answer further below

If an Upper Context is saved it must be restored and if lower context is stored it must be restored and if an opposite happened the Trap mentioned would be taken.

If SVLCX is used at the start of a function call, Task or an ISR then at the end it must have RSLCX.


If it is missed then as per the first line in the above sub section the Upper Context is automatically loaded and it may leads to Trap.

So, to avoid this you must always ensure the SVLCX and RSLCX (if usage is required) in the function calls, Tasks or ISRs. The Upper context saving & restoring is taken care by the CPU.





Thanks for your reply! The problem appears when I "make" a lot of interrupt on my ERU. In normaly execution It not happens, It seems like the OS can'd handle a lot of consecutive interrupt. I understand what you say, but How can I "must always ensure the SVLCX and RSLCX (if usage is required) in the function calls, Tasks or ISRs"?