• State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 22 subscribers
  • Views 1369 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

EXTS instruction sometimes doesn't work in CLASS B trap handler

Sebastian Raizer

Hi,
I've got exactly the problem as in this thread:
http://www.keil.com/forum/docs/thread171.asp

That was 6.5 years ago! Have you heard of a fix of some kind for this problem. The workaround is very complex and I'd rather not use it.
In my program, the EXTS instruction sometimes works and some other times is ignored and I can't find out why.

Parents
  • 0 in reply to Chris Wunderlich

    After one week working on this problem, I finaly found the cause and one solution.
    The instruction EXTS is designed so that the EXTended sequence is terminated if a class B trap occurs. Here is the warning text in the instruction set manual:
    "CAUTION: When a Class B trap interupts an ATOMIC or EXTended sequence, this sequence is terminated, the interrupt lock is removed and the standard condition is restored, before the trap routine is executed! The remaining instructions of the terminated sequence that are executed after returning from the trap routine will run under standard conditions!"

    For this mater, in the description of this instruction, there is:

    DO WHILE ((count) != 0 AND Class_B_trap_condition != TRUE)

    So what happens when this instruction is used in a class B trap function? Aparently, nothing is specified in that case. And according to this code, it is just ignored! And that is what I got, most of the time. I have no idea what Class_B_trap_condition means but acording to the tests I've done, it seems to mean "all the class b request flags in TFR are 0." Therefore, once the bits have been cleared, the instruction EXTS is working fine. My solution was then to make a copy of the TFR register, to clear it, and then to work on the copy.

Reply
  • 0 in reply to Chris Wunderlich

    After one week working on this problem, I finaly found the cause and one solution.
    The instruction EXTS is designed so that the EXTended sequence is terminated if a class B trap occurs. Here is the warning text in the instruction set manual:
    "CAUTION: When a Class B trap interupts an ATOMIC or EXTended sequence, this sequence is terminated, the interrupt lock is removed and the standard condition is restored, before the trap routine is executed! The remaining instructions of the terminated sequence that are executed after returning from the trap routine will run under standard conditions!"

    For this mater, in the description of this instruction, there is:

    DO WHILE ((count) != 0 AND Class_B_trap_condition != TRUE)

    So what happens when this instruction is used in a class B trap function? Aparently, nothing is specified in that case. And according to this code, it is just ignored! And that is what I got, most of the time. I have no idea what Class_B_trap_condition means but acording to the tests I've done, it seems to mean "all the class b request flags in TFR are 0." Therefore, once the bits have been cleared, the instruction EXTS is working fine. My solution was then to make a copy of the TFR register, to clear it, and then to work on the copy.

Children
  • 0 in reply to Sebastian Raizer

    I've just checked on the latest version of the instruction set manual and this has been clarified by the following text:
    "Within a ClassA or ClassB trap service routine EXTend instructions do not work (i.e. override the DPP mechanism) as long as any of the ClassB trap flags is set."
    However, I've seen one example where it did work and that confused me. That just means "do not work" should be understand "should not be used".

    So my conclusion is: allways check that you have the latest version of the manual!