Strange behaviour on NiosII/f

[Altera_Forum]

Hi All, 

 We are using Nios for a while now and recently ported our code to NiosII. Everything was running stable on a NiosII/s core. Then I tried to run the same code on a NiosII/f and it failed terribly, even when I turned on the 'always_bypass_dcache' option in the .ptf file! After some research I discovered that that our '_disable' macro caused the problem. This macro takes care of disabling the interrupt:  #define WR_IENABLE(val) asm volatile (  "WRCTL ienable, %0;"  : /* no outputs */  : "r" (val) ); # define _enable() WR_IENABLE(0xffffffff) # define _disable() WR_IENABLE(0x00000007) Interrupts 0,1 and 2 are used for 'non maskable' interrupts, the rest can be disabled and enabled with this macros. The problem is solved when I put a 'flushp' instruction after writing the IENABLE register in the '_disable' macro. It seems that on a NiosII/f core, sometimes something goes wrong directly after writing the IENABLE register if the pipeline is not flushed directly. I saw very strange behaviour. For example, NULL pointer exceptions caused by instructions directly after the disabling of interrupts (for detecting NULL pointer exceptions, we generate an interrupt on accessing address 0-7FF). Can anybody explain this strange behaviour?  Kind regards, Tim Brugman

[Altera_Forum]

Hi again, 

 Can anybody (maybe from Aletra?) explain this? It seems that instructions directly after the WRCTL instruction get wrong values from the registers (in some cases). I can't imagine that this is a feature, so it must be a bug in the /f core. Or is a 'flushp' required after the WRCTL? I did not find anything about it in the manuals.  Kind regards, Tim Brugman.

[Altera_Forum]

This indeed is a bug in the Nios II/f core. 

It has to do with clearing an ienable bit when its associated interrupt into the CPU is active. It has been fixed in our 1.1 release that will be available very soon.  The effect of the bug is to cause a spurious interrupt. The CPU thinks an interrupt has occurred so it branches to the exception handler.  Depending on your exception handler code, you get a different effect. If you are using the HAL with the unimplemented instruction emulation code enabled (the default), it will execute the equivalent of one of the multiply/divide instructions. Unfortunately, this looks to the programmer like one of the registers gets randomly trashed.  The flushp is not required. If you need a workaround, I'd try putting a nop instruction after the wrctl if you are using the HAL. This way the multiply/divide emulation code will try to write r0 which is ignored. Of course, I'd recommend switching to Nios II 1.1 which completely fixes the problem.