TC5 Interrupt and WAI instruction problem

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

TC5 Interrupt and WAI instruction problem

跳至解决方案
2,361 次查看
oilslick
Contributor II

I am porting an existing HC11 assembly language application to the MC9S12X512DT. So far I have only enabled the Time of Day interrupt using TCNT and the TC5 output compare function. The first two interrupts occur and process properly. The application encounters the WAI instruction before the next interrupt can occur. A 3rd interrupt occurs while in the wait state and processes properly. Before the 4th interrupt occurs, the same WAI instruction is encountered. This time the application hangs in the wait state as it appears that the TOD interrupt has ceased to function.

 

I am using an in circuit emulator for debugging. I set breakpoints for both the TOD interrupt vector and the WAI instruction. When the 1st WAI instruction is encountered, the ICE breaks. If I step the ICE, it goes right to the TOD vector (as expected). When the 2nd WAI instruction is encountered, I do the same thing. However, this time the ICE hangs up and it requires a reset to recover, which wipes out all of the CPU register states that might have held some useful information.

 

I can change clock pre-scalars so that the interrupts occur more frequently which causes the failure mode to occur after the 6th or 12th interrupt. 

 

Once again, this is an existing application that runs fine on the HC11 platform, which tells me that I'm likely doing something wrong in the CPU configuration.

标签 (1)
0 项奖励
回复
1 解答
1,443 次查看
oilslick
Contributor II

KEF it looks like you have nailed the issue. When I stop at the ISR breakpoint I see that the IPL changes from "0" to "1". When it hits the WAI the first time, the IPL is "0" but when it hits the WAI the second time, the IPL is still "1". This is where it hangs. If I change the IPL back to "0" the program hits the TOD ISR as expected.

The original programmer wrapped the application code in an "OS", which is essentially a Task Scheduler/Handler. In doing that a lot of very confusing Stack manipulation is done. On top of that his code does not provide for the 10 byte stack frame.

I believe you have pointed me in the right direction so I will flag this issue as Solved.

Thanks very much for your help.

在原帖中查看解决方案

0 项奖励
回复
4 回复数
1,443 次查看
kef
Specialist I

Is it possible your code performs jump from ISR insteat of RTI? Maybe jump to start of program with intention to do poor software reset? That could explain why interrupts may stop working. Interrupt priority level is not restored if you jump from ISR instead of normal return using RTI instruction.

0 项奖励
回复
1,443 次查看
oilslick
Contributor II
No "jmp" in the ISR. As I mentioned, this is existing code and the problem does not occur when running on the HC11 platform.
0 项奖励
回复
1,443 次查看
kef
Specialist I

Yes, I saw you mentioned your code works on HC11. But HC11 interrupt controller doesn't have interrupt priorities and it was OK to jump from HC11 interrupt routine to startup code. This won't work on S12X, unless you additionally restore interrupt priority to reset default priority level of IPL=0.

 

I think your problem description is not enough to tell something more. If it matters, I don't have any problems with WAI instruction on S12X.

0 项奖励
回复
1,444 次查看
oilslick
Contributor II

KEF it looks like you have nailed the issue. When I stop at the ISR breakpoint I see that the IPL changes from "0" to "1". When it hits the WAI the first time, the IPL is "0" but when it hits the WAI the second time, the IPL is still "1". This is where it hangs. If I change the IPL back to "0" the program hits the TOD ISR as expected.

The original programmer wrapped the application code in an "OS", which is essentially a Task Scheduler/Handler. In doing that a lot of very confusing Stack manipulation is done. On top of that his code does not provide for the 10 byte stack frame.

I believe you have pointed me in the right direction so I will flag this issue as Solved.

Thanks very much for your help.
0 项奖励
回复