MC56F8255: Do-loop works not correct with fast interrupt

[ulrichneumayer]

Hello,

i have the following problem:

- MC56F8255VLD
- Core running with PLL at 60MHz
- SPI is activated in slave-mode running with a frequency at 10MHz
- SPI-receiver-full-IRQ configured as fast-interrupt-irq
- every 1,6us occurs an SPI-receiver-full-irq

In the main-loop i have a do-loop. In the do-loop the Accumulator B is incremented. The do-loop is executed 19 times. At the beginning the accumulator is cleared, so after the do-loop the accumulator should have the value of 19. Dependent of the number of NOPs in the do-loop the accumulator have the value 19 or 20. The value 19 is correct, the value 20 is not correct. The value 20 depends of the number of the NOPs and only happens when the SPI-receiver-full-irq is enabled. The SPI-receiver-full is a fast-irq.

Here is the Code:

_MainLoop:
  CLR       B

  DO        #19,_DoLoop
      INC.L     B
      ;// No NOP  --> O.k.
      ;//  1 NOP  --> O.k.
      ;//  2 NOPs --> fail
      ;//  3 NOPs --> O.k.
      ;//  4 NOPs --> fail
      ;//  5 NOPs --> O.k.
      ;//  6 NOPs --> fail
      ;//  7 NOPs --> O.k.
      ;//  8 NOPs --> fail
      NOP
      NOP
_DoLoop:    
 ;// Here i check if the result is correct:    
 MOVE.W  B0,Y1
 CMP.W   #19,Y1
 BEQ     _ResultIsCorrect
 NOP
 NOP

_ErrorLoop:
  ;// Result is not correct --> Error-Loop
 BRA _ErrorLoop
   

_ResultIsCorrect:
  BRA _MainLoop

Here is the SPI-receiver-full-irq-code:
SPIRxFullIRQ:
    MOVE.W    X:SPI0_SPDRR,Y0
    FRTID                   
    NOP
    NOP

The 56F8322 and 56F8335 DSPs don't have this problem!
What is the reason for this behavior and what can i do to avoid this problem?

Many thanks for your help!
Best regards
Ulrich Neumayer

Attachment: The Project

Original Attachment has been moved to: Project.rar

[xiangjun_rong]

Hi, Ulrich,

I am sorry for the delay.

As you know that MC56F8255 and MC56F83xx use the same DSP56800E core, it is unusual that the 56F8322 and 56F8335 DSPs don't have this problem, but the MC56F8255 has the issue.

If you disable fast interrupt, does the phenomenon happen or not? I suppose that you have to save the hardware loop register in ISR.

I suggest you read the EB813 which I attached, it addresses the Hardware DO looping issue.

Hope it can provide any clue.

BR

Xaingjun Rong

[ulrichneumayer]

Hello Xiangjun Rong,

many thanks for your answer.

- it is possible that the 56F8322 and 56F8335 has the same problem but in my case it possibly has not appeared (because of code alignment --> NOPs in the example above)

- no, if the fast interrupt is disabled everything is o.k!

- the problem described in "EB813.pdf" is another problem and has nothing to do with my problem. I dont' use the "INTERRUPT_SAVEALL" and "INTERRUPT_RESTOREALL"-pragmas and the fast-IRQ is not interrupting another IRQ (there is no other IRQ aktiv, it is only one fast-IRQ aktiv, so the fast-IRQ is not interrupting another IRQ). And it is not a initialisation-problem!

- saving the LC register is no option for me because the fast IRQ should be as fast as possible (this is the reason why i'm using a fast IRQ. In my case, only the fast IRQ produces  a CPU load from about 11,5%)

- what is the reason for your solution i should save the LC-register to the stack in the fast-IRQ? The fast-IRQ don't change or uses the LC-Register and the fast-IRQ is not interrupting another IRQ. Apart fom this saving LC-register is not possible because at the end of the fast-IRQ you have to restore the LC-Register back from the SP but after the "FRTID"-instruction it is not permitted to do something like this: "move.l x:(sp)-,lc" in the delay-slot of the FRTID-instruction.

I think it's a Problem with the "FRTID" instruction in association with an hardware-DO-loop (when an fast-IRQ is interrupting an hardware-DO-loop at the beginning or ending of the DO-loop and the fast-IRQ is executing the FRTID-instruction) and so, it is a bug in the chip. Maybe you would be able to inform the development department about the problem. 

For me it means: Never use DO-Loops together with fast IRQs

I solved the Problem so:

- in time critical areas i duplicated the code with the "DUP" and "ENDM" preprocessor macro instead of using a hardware DO-loop. So the code execution is as fast as possible, but the code size is bigger. But code size is no problem for me because the flash is big enough.

- in no time critical areas i'm using a normal Loop instead of using a hardware DO-loop

Best regards
Ulrich Neumayer

[xiangjun_rong]

Hi, Ulrich,

First of all, it is okay to use a workaround as you have done.

Regarding the cause of the issue, as you know the FISR and PC registers are push/pop automatically when you enter/exit the fast interrupt ISR, so I think the FISR register is the only way to generate the issue as the EB813 does, although I do not know the detailed mechanism.

Hope it can help you

BR

Xiangjun Rong

[ulrichneumayer]

Hi Xiangjun Rong,

thank you for your help!

The reason why i think it's the "FRTID"-instruction is this: In the year 2008 i had a similar problem with the 56F8322. Exakt the same example as above, but instead an fast-IRQ it was a normal IRQ. The normal IRQ was finished with an delayed "RTID"-instruction. When the do-loop was interrupted by the normal IRQ at a special point, the loop-counter was changed and the loop was executet one time less as expected. Also exakt the same problem as above, but instead a fast-IRQ a normal IRQ with a delayed "RTID"-instruction. I told Freescale the problem and yes, they answered yes, it is a CPU bug! The solution from Freescale, i should use no delayed-instruction, means i should replace the "RTID"-instruction with a normal "RTI"-instruction. I made this and everything was o.k.! In the above case, the fast-IRQ only can finished with an delayed instruction (FRTID). So a fast-IRQ can not finished without a delayed instruction. So, here it exist no solution.

Best regards,

Ulrich Neumayer