0

FreeRTOS V7.5.3 port for ALL 16 bit pics with hardware stack checking (SPLIM)

Mike

October 31, 2013 23:12

None

Follow

UPDATE: The current zip file contains all the fixes discussed below for 7.5.3. I have created a new topic for V8

UPDATE: MY ORIGINAL UPLOAD WAS FAULTY (very red face)

UPDATE: there is a bug, see comments below - I ma waiting for a response from Microchip before updating the zip file

I let a change slip through that was for my system that would cause the timer interrupt to never occur (with configKERNEL_INTERRUPT_PRIORITY set to 1 as is the default) the current attachment should be correct

 

starting concurrently with Martin I started using a dsPIC33E and needed to make changes - I went overboard but...

This port is only the two files portmacro.h and port.c. It no longer uses MPLAB_DSPIC_PORT and doesn't have  separate assember files.

It sets up SPLIM and uses it for all tasks, but not for the initial main program stack (which is abandoned after the scheduler starts.

As a note, there is no problem using EDS memory (i.e. >32k ram) in the application, it just can't be used by FreeRTOS nor by the stack.

Also the new compiler xc16 v1.20 has the option -mno-eds-warn to disable the warnings Martin talks about.

mike

16bitPICs.zip

• Facebook
• Twitter
• LinkedIn

41 comments

• 0
  
  Adam March 09, 2014 15:58

  I've tried to port this files for this new FreeRTOS 8.0 version.

  I think that there is a problem with this procedure:

  StackType_t *pxPortInitialiseStack( StackType_t *pxTopOfStack, TaskFunction_t pxCode, void *pvParameters )
  {
  unsigned short stack_save2, stack_save3;
  /* Setup the stack as if a yield had occurred.

  Save the low bytes of the program counter. */
  *pxTopOfStack++ = ( StackType_t ) pxCode;
  /* Save the high byte of the program counter. This will always be zero
  here as it is passed in a 16bit pointer. If the address is greater than
  16 bits then the pointer will point to a jump table. */
  *pxTopOfStack++ = 0;

  /* the following is a little awkward, but has the advantage that it mimics vPortYield */
  asm volatile( "MOV W15,%0" :"=r" (stack_save2): );
  asm volatile( "MOV %0,W0" : :"g" (pvParameters) ); /* pretend we're passing pvParameters */
  asm volatile( portSAVE_CONTEXT );
  asm volatile( "MOV W15,%0" :"=r" (stack_save3):);
  memcpy( pxTopOfStack, (char *)stack_save2, stack_save3-stack_save2 );
  asm volatile( "MOV %0,W15" : :"r" (stack_save2): ); /* pop off the context stack frame */
  *pxTopOfStack = ( StackType_t ) 0; /* clear the SR register */

  pxTopOfStack += ( stack_save3-stack_save2 ) / sizeof( StackType_t );
  /* Finally the critical nesting depth. */
  *pxTopOfStack++ = 0x00;
  /* the following is done by the macro traceTASK_CREATE */
  //*pxTopOfStack++ = ( StackType_t )pxEndOfStack-16; /* SPLIM - enough space for the exception handler */
  return pxTopOfStack;
  }

   

  I think that this is not properly restoring SPLIM register in vPortYieldfake()...

   

• 0
  
  Adam March 09, 2014 16:00

  And by the way I'm trying to use this on dsPIC33EP512MC806

• 0
  
  Mike March 09, 2014 17:08

  Adam,

  You are correct (at least that there is a problem), the bug(s) are in vPortYieldfake().

  I have been waiting for a response from Microchip w.r.t. interrupt disabling, before posting the fix. I just realized (would you believe yesterday!) that I had not got a response and re-asked).

  Regardless, I believe that the right code for portRESTORE_CONTEXTend  is

  #define portRESTORE_CONTEXTend                                                                                \
          "MOV    _pxCurrentTCB, W0        \n"        /* Restore the stack pointer for the task. */                \
          "MOV    [W0], W0                \n"                                                                    \
          "MOV     #7 << 5, W2                \n"        /* disable interrupts to set SPLIM and stack*/                \
          "MOV    W2, SR                    \n"            \
          "MOV    [--W0], W1                \n"       /* this instruction can be interrupted (instead of NOP) */                 \
          "MOV    W1, SPLIM                \n"                                                                    \
          "MOV    W0, W15                    \n"                                                                    \
          "MOV #" STRINGIFY_E(configMAX_API_CALL_INTERRUPT_PRIORITY) " << 5, W2\n"                            \
          "MOV    W2, SR                    \n"                                                                    \
          "POP    W0                        \n"        /* Restore the critical nesting counter for the task. */    \
          "MOV    W0, _uxCriticalNesting    \n"                                                                    \
  
  

  The question for Microchip was whether or not 1 instruction after the write to the SR register was enough to guarantee that interrupts were really disabled.

  The disabling code could have been moved to before the loading of _pxCurrentTCB, but I wanted to minimize interrupt disable time (rather silly actually, but...)

   

  IF you use the dsp math libraries you need to save MOCON in all interrupts as in

  void __attribute__((__interrupt__, auto_psv, __save__(MODCON))) configTICK_INTERRUPT_HANDLER( void )
  {
      MODCON = 0xF0;

  for the EP series (have used dsPIC33EP512MC202 several times).

   

  I also have version (the one I actually use) that allows fully nested interrupts.

  I apologize for not reporting the bug/fix earlier, but  no on seemed to be using this code, I was waiting for time to  migrate to V8, waiting to publish my new stuff....

  and of course the real reason I was lazy.

  Please send me a message and let me know how it goes, and if I can be of any help

  mike

• 0
  
  Adam March 09, 2014 17:37

  Your patch has improved things a little bit.

  So far I was unable to run single task for even one single time.

  Now every tas runs once before simulator throws this error:

  Trap due to unimplemented FLASH memory access, occurred from instruction at 0x000002

• 0
  
  Mike March 09, 2014 18:42

  Adam,

  I see that you set the timer1 interrupt priority to 7, that will not work.

  A it must be set to to configKERNEL_INTERRUPT_PRIORITY.

  All interrupts that call a FreeRTOS function must run at configKERNEL_INTERRUPT_PRIORITY, and that includes the timer1 interrupt.

   

  mike

• 0
  
  Adam March 09, 2014 21:45

  I've got a lot of troubles figuring what is what. Could You please post some examples?

  Best Regards Adam

• 0
  
  Mike March 11, 2014 16:22

  Adam,

  I'm not sure what you are trying to figure out. Your port to V8 was incorrect where you set the timer1 interrupt priority.

  The bug in the code only occurs if the code size > 64K or the code size is smaller than the memory used, which is why it took me a while to discover it.

  If you don't understand the interrupt priorities then search for configKERNEL_INTERRUPT_PRIORITY in the config section of the help for some guidance. (I initially got it confused so you wouldn't be alone)

  As for general help I would suggest the main support forum and perhaps starting out with the sample project in the main distribution, substituting port.c and portmacro.c.

  I have never tried either the sample, nor the simulator (FreeRTOS nor Microship's) so I am not much help there.

  My programs are rather large, complicated and depend on peripherals so they are also not much help.

  If you are using a simulator, you may be better off starting with the standard port (and a different processor) until you get the FreeRTOS kinks out, before trying this port.

  I'm afraid that migrating to V8 is a low priority for me right now (I have more than 10 "things" running on V7), but it looks like the changes that were made relate to type names and should not be an issue.

  mike

   

• 0
  
  Eric March 13, 2014 17:14

  Hey Guys,

   

  I found a small issue with this port as well, on the dsPIC33EP512.  This is referring to posted zip file by the way.  I'm not sure if this will apply on your targets, but I thought I'd like to share it with you guys, since it's helped me out a lot.  

  It looks like in the context switch, when SPLIM is popped off the stack and set, it seems to point to the next available stack location, instead of the previous pointer to the top of the stack.  It looks like then when you do a context restore, SPLIM gets set with 0xA5A5 (i.e. the initial stack fill pattern value).  I believe that before the context switch occurs the top of stack is the last thing pushed onto the stack, but it is not popped off of the stack.  

  This seemed to work ok with a small number of tasks, but after a certain point I started getting a stack overflow exceptions resulting from SPLIM being exceeded.  I made a small patch to the code in my setup which seems to rectify the issue, and so far everything seems to be working.  

   

  Basically, looking at the original upload zip file (from October 31, 2013) if you change line 199 of port.c to include a decrement in W1 as follows:

   

  MOV [W1], W1  ==> MOV [--W1], W1

   

  The new code would then be:

  #define portRESTORE_CONTEXTend \
  "MOV _pxCurrentTCB, W0 \n" /* Restore the stack pointer for the task. */ \
  "MOV [W0], W1 \n" \
  "MOV [--W1], W1 \n" \
  "MOV W1, SPLIM \n" \
  "MOV [W0], W15 \n" \
  "POP W0 \n" /* SPLIM - but already set */ \
  "POP W0 \n" /* Restore the critical nesting counter for the task. */ \
  "MOV W0, _uxCriticalNesting \n"

   

  I hope this helps you guys.  

   

  Cheers,

   

  Eric

   

• 0
  
  Mike March 13, 2014 20:22

  Eric,

  You are absolutely correct about the fix for the bug. In addition as soon as I fixed that I discovered that on the return from vTaskSwitchContext. interrupts can be enabled hence the additional code I added above to disable the interrupts before changing SPLIM and the stack pointer.

  I still haven't heard a response from microsoft as to how many instructions it takes to disable interrupts after writing to the status register (know it is at least one and on 32MHz dsPIC33EP one is sufficient), before updating the zip files.

  mike

• 0
  
  Eric March 14, 2014 20:23

  Hi Mike,

   

  That's great!  Sorry I didn't realize that you'd posted that already.  Thanks for getting back.  Looking forward to hearing what Microchip has to say.

   

  Eric

   

• 0
  
  Anton April 01, 2014 06:40

  Hi Eric,

  Could you please post the final code with all modified files?

  Thanks,

  anton

• 0
  
  Eric April 16, 2014 19:04

  Hi Anton,  

  Sorry for the very late reply,  I've pretty much been using Mike's latest update, which only touches port.c.  The files are in the attached zip.  Hope they work for you!

  Cheers,

  Eric

• 0
  
  Anton May 02, 2014 09:29

  thank you! it works

• 0
  
  Bernard July 11, 2014 08:36

  I had a similar problem with FreeRTOS V8.0.2, Moving to V8 was quite rocky since it broke a lot of things for me, but the stack related issues i spent most time on and the ZIP file from Eric worked like a charm. Thanks!

• 0
  
  Tom Lafleur December 27, 2014 16:05

  I replaced the port.c and portmacro.h from the April 16, 2014 files above in my build with FreeRTOS 8.2.1 and 8.2RC1. But I get lots of compiler error... most of the time,  this is an indication that I did something wrong...

  Any other setting or changes that I need to make to use the EP processor??

  thanks

   

   

• 0
  
  Eric January 07, 2015 18:30

  Hi Tom,

  I did some experiments with FreeRTOS v8.1.2 and it looks like they've renamed a lot of the internals.  In principle, I think the port should work for FreeRTOS v8 with a few changes.  I got it to compile by making the following changes to portmacro.h:

  68a69,70

  > #include <stdint.h>
  >
  97a100,103
  > typedef portSTACK_TYPE StackType_t;
  > typedef short BaseType_t;
  > typedef unsigned long UBaseType_t;
  >
  99,100c105,107
  < typedef unsigned portSHORT portTickType;
  < #define portMAX_DELAY ( portTickType ) 0xffff
  ---
  > typedef unsigned portSHORT portTickType;
  > typedef uint16_t TickType_t;
  > #define portMAX_DELAY ( TickType_t ) 0xffff
  102,103c109,111
  < typedef unsigned portLONG portTickType;
  < #define portMAX_DELAY ( portTickType ) 0xffffffff
  ---
  > typedef unsigned portLONG portTickType;
  > typedef uint32_t TickType_t;
  > #define portMAX_DELAY ( TickType_t ) 0xffffffffUL
  104a113
  >
  111c120,121
  < #define portTICK_RATE_MS ( ( portTickType ) 1000 / configTICK_RATE_HZ )
  ---
  > #define portTICK_PERIOD_MS ( ( portTickType ) 1000 / configTICK_RATE_HZ )
  >

  This patch seems to work with both FreeRTOS v8.1.2 and FreeRTOS v7.5.3, although I haven't really tested it extensively.  On the surface, it compiles, runs, and seems to context switch correctly (at first glace).  I haven't given it any amount of solid testing, though so no promises.  If you'd like, give it a try and let me know if it works for you.

   

  Cheers,

  Eric

   

   

• 0
  
  Daimonion January 20, 2015 13:01

  Hi @ all

   

  Actually i'm trying to learn to walk with freertos on a dspic33e64mc206.

   

  For this i downloaded the current freertos version 8.1.2 and the latest patch from eric attached in his post from April 16, 2014, 20:04

   

  After implementing the patch in portmacro.h i can't compile due to an further linkerexception which doesn't find "configMAX_API_CALL_INTERRUPT_PRIORITY".

  I found this define in several FreeRTOSConfig.h files but not in a file which is for dspic. 

  For my tests i will define it myself but i don't know exactly whith which value i can define it. 

  The dsPIC33E has 8 priority levels. 

  Is 8 the best Value for this define?

• 0
  
  Israel Lot January 20, 2015 19:53

  I'm trying it on a dsPIC33EP512GP806. 

  There's something weird going on, after some seconds the pic will crash and restart. On debug session there's nothing indicated, just that the session is halted.

  Does anyone have a perfectly working project for the dpPic33E that could share?

• 0
  
  Daimonion January 21, 2015 11:18

  Hey Mike. Tomorrow I will have a meeting with microchip fae and an microchip evangelist which sure can answer your question.
  
  Can you post your question so that I can forward it to the guys?
  Or easier:
  Which status register do you mean?
  
  Regards
  Thomas
• 0
  
  Daimonion January 21, 2015 12:30

  @Israel Lot

  had this behaviour yesterday. After increasing the HeaP Size to 5120 (like it was before my changes) it worked for me. 

• 0
  
  Israel Lot January 21, 2015 12:42

  @Daimonion My heap size is 5120 already. 

  I'm also facing problems trying to set the clock with external crystal. 
  Do you have by chance a working project for the dspic33e? I'm new to freertos, that would help me a lot!

   

• 0
  
  Daimonion January 21, 2015 13:54

  CockSetup is done by a seperate routine which i inserted in the main routine. For my test i'm using the internal clock driven to 120MHZ and 60MIPs.

  Didn't found any other clocksetup in my freertos files so i decided to use my own. 

  Basis of this routine is the example in the reference manual. dsPIC33E FRM - Section 07 - Oscillator - DS70580B Table 7-1 where an external setup is also described.

   

  Which value does configMAX_API_CALL_INTERRUPT_PRIORITY have in your setup?

• 0
  
  Mike January 21, 2015 15:21

  @Daimonion,

  I haven't looked at V8, but I'm surprised you need configMAX_API_CALL_INTERRUPT_PRIORITY. Regardless it should be set to configKERNEL_INTERRUPT_PRIORITY (which defaults to 1 I believe).

  In this version of the port there are no nested interrupts and all interrupts that call RTOS functions MUST run at the same priority (configKERNEL_INTERRUPT_PRIORITY)

  Interrupts that do NOT call RTOS functions are free to use higher interrupts and will not be blocked by any freeRTOS code.

   

  @Thomas - I did get a reply from Microchip (they even phoned me!), but in the end their response was if it doesn't work with no nops and it works with 1 nop use 1 nop!

  Which I guess is fine, until it takes 2 nops!.

  Regardless, with the code above (from Eric's zip) I have not had a problem.

  mike

• 0
  
  Tom Lafleur January 22, 2015 05:21

  Today, I again tried to port a simple demo to the dsPIC33E processor using Eric files...
  
  

  The issue I was having is that his files are for FreeRTOS 7.5.3 and I was using 8.2... In ver 8

  a number of names were changes in the FreeRTOS code and I had also updated them in my code, thus

  giving me allot of error... So with allot of digging into the code, I have updated Eric file to support the 8.2 naming convection and I will

  post them on the FreeRTOS interactive site...
  
  

  I now have my full project running on Ver 8.2 on a dsPIC33EP256GP504 chip at 60Mhz.

  Richard: We need an official supported port, the dsPIC are VERY popular devices...

• 0
  
  Daimonion January 22, 2015 07:40

  Tom, can you say me which value configMAX_API_CALL_INTERRUPT_PRIORITY in your version has?

• 0
  
  Tom Lafleur January 22, 2015 15:38

  You should read and understand how this works by reading the reference manual...

  http://www.freertos.org/a00110.html

  This is what I have in my current project...

  ~~~~~~

  /* Interrupt nesting configuration. */
  #define configKERNEL_INTERRUPT_PRIORITY         1
  #define configMAX_SYSCALL_INTERRUPT_PRIORITY    3  // deprecated
  #define configMAX_API_CALL_INTERRUPT_PRIORITY   3

  ~~~~~

• 0
  
  Mike January 22, 2015 17:58

  I have not used V8 yet, and my development system is down, so I may be wrong, but ...

   

  As per http://www.freertos.org/a00110.html the pic24/dspic24 ports does NOT implement configMAX_API_CALL_INTERRUPT_PRIORITY and in V7 it is not used (you should be able to use your code development software to check if it is used anywhere in V8, but I doubt it), and as such it doesn't matter what it is defined to be.

  More importantly the port does not implement interrupt nesting. All interrupts that call (directly or indirectly) FreeRTOS functions MUST be at configKERNEL_INTERRUPT_PRIORITY. Interrupts that do not call FreeRTOS may be nested and set to priorities >= configKERNEL_INTERRUPT_PRIORITY.

  mike

• 0
  
  Israel Lot January 28, 2015 20:52

  So should I enable or disable HW interrupt nesting ( NSTDIS bit ) ?

   

• 0
  
  Mike January 28, 2015 22:17

  Disabling nesting is generally a bad idea - at the very least it can introduce poorly understood behaviour ( you can look at http://www.freertos.org/FreeRTOS_Support_Forum_Archive/March_2010/freertos_PIC24F_Interrupts_Issue_Warning_Newbie_insid_3630318.html and http://www.microchip.com/forums/m568363.aspx - if you dare!)

  In particular neither the original pic port, nor mine will work with nesting disabled.

  mike

• 0
  
  Israel Lot January 28, 2015 23:33

  Thanks mike,

  I'm actually facing a problem very much like this one http://www.freertos.org/FreeRTOS_Support_Forum_Archive/January_2012/freertos_Yield_from_ISR_and_Tick_Interrupt_Collision_4984768.html
  I could trace it to a point where it enters the Send function of a queue, and the queue data is magically corrupted so it hangs while the interrupts are disabled.