I just ported our OS (Linux based) from the NET+50 to the NS7520. Because of the change in port muxing, we moved an external device interrupt from PORTC3 (IRQ3) to PORTC0 (IRQ0). I am unable to make this work right. If I leave the interrupt masked, I can see the correct interrupt status in the Interrupt Status Raw Register. However, if I unmask the interrupt, asserting the interrupt line seems to cause the processor to hang. (And no, as far as I can see, the ISR is not being called). For testing, we jumpered the interrupt signal over to PORTC2 (IRQ2) and I moved the ISR over to that interrupt and it worked correctly. I have looked over the ISR support code and, as far as I can see, there are no bugs specific to interrupt zero. I have not ruled out a software bug but it looks like a hardware bug. Has anyone here has successfully used IRQ0? Thanks
To the best of my knowledge NET+OS doesn’t use FIRQ. The default handler installed by the BSP treats an FIRQ exception as a fatal error (crash_for_debug) and halts the system. In addition to this since NET+OS does not use FIRQ interrupts, the IRQ handler does not contain special handling for FIRQ interrupts (it dispatches them according to their interrupt source default priorities). However, as you know you can modify the irq handler to install a FIRQ handler. Please find enclosed a complete project showing the use of the FIQ with hardware timer 2 on our silicon. The attached code works with GHS 2.1 and GHS 3.6.1 that comes with Net+Os v6.0. Here are some explanations w/ regard to the code supplied with this mail. You may want to use this as a starting point for your own implementation: The FIQ handler is placed in a separate section, which allows you to place it in cache ram of the NET+50 just by changing the link address of this section inside the linker control file. Also, please be aware of the fact that the NET+OS initialization code disables FIQs by default. If you want to trigger FIQs, you explicitly must not set the F-Bit in the corresponding CPSR. The code in question is located inside init.s: # setup the IRQ stack # MOV R5, #Mode_IRQ:OR:I_Bit:OR:F_Bit ; No interrupts MOV R5, #Mode_IRQ ORR R5, R5, #I_Bit —> ORR R5, R5, #F_Bit MSR cpsr_all, R5 @ Set IRQ Mode MOV R13, R0 @ set the stack pointer LDR R1, =IRQ_STK_SZ @ Compute the top of the SUB R0, R0, R1 @ FIQ stack in R0 Comment out the line marked with —> in your init.s to allow for FIQs interrupting any IRQs. #now,we finished out memory and hardware initialization, let’s go to #Green Hill code to do C initialization we need to be in SVC mode to do this. #setup the real SVC stack, no need to copy over the temporary stack #we used to make the call to ncc_init() since we shouldn’t have #anything pushed on the stack right now. # MOV R5, #Mode_SVC:OR:F_Bit MOV R5, #Mode_SVC —> ORR R5, R5, #F_Bit MSR cpsr_all, R5 Comment out the line marked with —> in your init.s to allow for FIQs in general. I hope this will assist you in general. Let us know if you would have further related questions.
Just a follow up. NS Tech Support reports that they have tested the NS7520 IRQ0 and were able to use it without problems (thank you). I guess it must be a SW problem though I still cannot see it.