Pic32 change RTOS timer to Timer5

Hi, I have a board with PIC32MX795F512L fitted, and am adding Microchips TCP/IP Stack…. I thus need to change the timer being used, as the MChip stack makes extensive internal use of Timer1. I know that this topic has been covered previously, by a Microchip App Note and various forum posts here etc. but these are now quite old…. I currently have it (almost ??) working using Timer5, having modified ‘port.c’. My board is however experiencing random ‘crashes’ and when I catch this in the ‘generalexceptionhandler’, I see the core software interrupt flag set – IFS1 = 2 – suggesting that this ‘might’ be related to FreeRTOS ??? SO – I am guessing that my changes are not fully correct (although the RTOS is working, task switching etc.). I just installed XC32 V1.22 (was using V1.21 until this morning) – which made no noticeable difference – although there are notes referring to Interrupt level changes in this compiler !!. I am using FreeRTOS V7.5.2 – but also see that a new FreeRTOS build (7.5.3) is now available, and that the code in port.c has changed. Also please refer to the forum discussion :
PIC32 - Using a different Timer
In this discussion it specifically mentions the change to use a new

define IFS0T1IF_MASK in ‘vPortIncrementTick’.

So as I am now confused by the various historic posts etc. – could someone please define the BEST steps now necessary to perform the Timer change – using the current FreeRTOS. Seems to me not to be limited to the interrupt handler but also to the initialisation routines and maybe somewhere else ??? I am wondering if there is now a ‘standardised’ or ‘recommended’ method to swap out the timer for Pic32 in FreeRTOS ? Many Thanks Best Regards Graham

Pic32 change RTOS timer to Timer5

In port.c the function that configures the timer is called vApplicationSetupTickTimerInterrupt(), but it is declared with weak linkage, so it can be redefined in your application code. The default vApplicationSetupTickTimerInterrupt() configures timer 1. You can copy and past the function into your application code, remove the “attribute(( weak ))” attribute, then update the implementation to use T5 in place of T1. If T5 is the same as T1 then that should be straight forward, simply change the T1 registers to T5 registers. If T5 is different to T1 then you will have to refer to the manual or other sample code to see how to generate a periodic interrupt from T5. The interrupt vector is defined by the constant configTICKINTERRUPTVECTOR, which can be defined in FreeRTOSConfig.h. If you don’t define configTICKINTERRUPTVECTOR then it will default to TIMER1_VECTOR. The one place you do have to edit the port layer (which is an omission on our part) is where the timer is cleared. In port.c there is the function vPortIncrementTick() which contains the code “IFS0CLR = IFS0T1IF_MASK;” That will need editing to clear timer 5. Regards.

Pic32 change RTOS timer to Timer5

I was faced with the same decision in this exact same situation and found that it is easier to change TICK.C in the MicroChip stack to another timer than to change FreeRTOS as the modifications are very simple anc contained to only TICK.C. Not only is this route simpler, but it allows one to upgrade to new versions of FreeRTOS without having to worry about previous changes to FreeRTOS that have to be carried forward. Until the new compiler change (at Version 7.3.0), upgrading (successfully) to new versions of FreeRTOS took less than 1 minute of copying new files and my MicroChip stack continues to work unchanged.

Pic32 change RTOS timer to Timer5

Guys, Sorry for the delay – been out of the office until today :-O – with only an iPad ;-). I decided to try Johns suggestion of moving the Microchip code to Timer 5 – working a treat – many thanks John for this tip. Much of the ‘older’ docs say this used to be difficult to do – as Microchip has a habit of ‘spreading references around’ (in my experience ;-)). So – its onwards and upwards. My ‘other two remaining issues are (I suspect)
  1. Interrupt related – causing the generalexceptionhandler to get invoked. May be that I am trying a long-running code and the software interrupt is failing somehow, normally my code yields manually…
  2. The other one (yes managed to do lots of reading whilst away 😉 looks like a known errata, when using SPI on the PIC32MX :-((. Seems to be a 1 bit error in setting the ‘done’ flag 1 spi clock bit early !! – this could easily be the cause of why my write to SPI FLASH chip is occasionally corrupting some chars on write – will try a few fixes :-O.
Thanks again for the swift support… Best Regards Graham

Pic32 change RTOS timer to Timer5

Guys, Sorry its not the core interrupt being triggered (well I suspect not!!). Was reading IFS0 when the changed bit was in IFS1 :-O. Adding exception code to try to track this one down…. Graham