Tick interrupt priority

Does anyone know the implications if the tick interrupt operates at the highest possible interrupt priority?

Im currently knee deep reverse engineering an old Cisco router with a 68030 processor, and had this crazy idea to try and run FreeRTOS on it, since the Coldfire port seems like it might just work out of the box. :upside_down_face:

By analysing the bootrom source I have found one timer that I am able to configure and could use for the tick interrupt, but it generates interrupts at IPL7. The FreeRTOS documentation seems to suggest that the tick interrupt should be the lowest possible priority, but I havent yet discovered a way to alter the priority that this timer generates, if it is at all possible (its implemented in some custom silicon, so I doubt I’ll be finding any datasheets any time soon).

Isn’t IPL 7 non-maskable? If so, it wouldn’t be suitable for the tick interrupt or for any interrupt that makes FreeRTOS API calls. :frowning:

1 Like

Yeah, non-maskable.

Guess I can forget about that idea then.

Well if you’re feeling motivated, you could use the timer interrupt to induce a lower-priority interrupt, and the ISR for the lower-priority interrupt could be the tick ISR.

I was just thinking about a way to work around this.

I had an idea to set some kind of flag, and then maybe in the idle hook use that to perform a tick?

It would mean that you could only tick once all ready tasks have run though, but with a lack of better options it may just have to do.

None of the 680x0’s built in exceptions can have priorities assigned to them as far as I know, so I guess I either need to find a way to adjust the priority generated by this timer, or find another timer that has a lower priority.

Oh right, there’s no INTC_FRC register or concept at all. Since 68030 doesn’t have the interrupt controller of the ColdFire, I don’t think the ColdFire port is suitable at all. See the implementation of portYIELD() for example.

1 Like

Ah! Ok, so I would likely have to create my own port then. But I guess luckily it looks like most of the context switching code might be re-useable, so hopefully minimal extra work.

So, I have found a source of lower priority interrupts.

Theres a Hitachi HD64570F serial communications controller on the board which just happens to have 4 timer channels in it that can be used to generate interrupts. This peripheral seems to be wired to IRQ 4.

Quite convenient, becuase the dual UART seems to be wired to IRQ 5. Theres also an ethernet controller, but it also generates interrupts at IRQ 4. Not ideal I suppose.

Still havent found any ability to change the priority levels (although I suspect because this was built for a specific purpose, the IRQs are fixed), but this is better than IRQ 7 anyway given I dont have much say in the matter. :slight_smile:

(edit: just realised Ive been saying IPL when I should probably be saying IRQ - got my head buried in signal names too much)