Pic32 change RTOS timer to Timer5

Kernel
1

egstevenson wrote on Tuesday, October 29, 2013:

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 ‘general_exception_handler’, 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 _IFS0_T1IF_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

2

rtel wrote on Tuesday, October 29, 2013:

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 configTICK_INTERRUPT_VECTOR, which can be defined in FreeRTOSConfig.h. If you don’t define configTICK_INTERRUPT_VECTOR then it will default to _TIMER_1_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 = _IFS0_T1IF_MASK;” That will need editing to clear timer 5.

Regards.

3

jfmeyer wrote on Tuesday, October 29, 2013:

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.

4

egstevenson wrote on Saturday, November 02, 2013:

Guys,

Sorry for the delay - been out of the office until today :open_mouth: - 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 general_exception_handler 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 :wink: 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

5

egstevenson wrote on Saturday, November 02, 2013:

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