0

FreeRTOS V8.2.0 port for ALL 16 bit PICs with hardware stack checking (SPLIM)

Mike

February 22, 2015 16:33

None

Follow

This is the same port as http://interactive.freertos.org/entries/28123677-FreeRTOS-V7-5-3-port-for-ALL-16-bit-pics-with-hardware-stack-checking-SPLIM-

except that I have merged all the changes in V8 (just name/typedef changes).

 

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 huge number of  eds warnings.

mike

16bitPICsV8.zip

• Facebook
• Twitter
• LinkedIn

20 comments

• 0
  
  Anton February 23, 2015 09:26

  Thank you Mike,

  Does it also works with the optimization level 1 on XC 16 v1.24?

  As soon as I switch to the level 1, I get error errCOULD_NOT_ALLOCATE_REQUIRED_MEMORY  in the function xTaskGenericCreate.

  anton

• 0
  
  Mike February 23, 2015 14:37

  Anton,

  I don't think this is related to this version of the port.

  Having said that, I usually run at level 1 (there used to be a bug at level 2+), but I am still using v1.21. I also don't have hardware/software that runs this code - I'm still running 7.5.3 (updating soon) and with a port that includes nested interrupts, so I can't be definitive and I did go through multiple code generation issues with XC16 and dsPIC33Es, but ...

  There is no (good) reason why adding optimization should make it fail. I have only used heap_1 and have not had issues, though I had to change the heap definition to

  static uint8_t __attribute__((far)) ucHeap[ configTOTAL_HEAP_SIZE ];

  in order to use larger heap sizes. This is always a good idea since the heap is always accessed by pointers and so suffers no penalties for being "far".

  You might want to define the macro traceMALLOC to do some debugging and see what is using all your heap, check your data model settings. You could perhaps look at what optimizations are added at level 1 and try/disable some.

  mike

  PS. there is (was) a warning generated (missing a cast )in traceTASK_CREATE macro in xTaskGenericCreate. I have updated the zip file to include the fix

• 0
  
  Tom Lafleur February 24, 2015 15:19

  Mike....

  I have your code running on my test bed, with dsPICEP512 and dsPICFJ128 at 40MHz without any errors for the last 48 hr on four boards....  All are using 4 DMA channels, two Uarts, 12 interrupts sources,  (with one that operates at 20KHz).  So in my opinion, it looks to be a robust port... Using XC16 1.24 with level 1, FreeRTOS 8.2.0, heap_4

  Thanks for the effort.... Maybe Richard will consider making your port an official port soon....
  
  

  i~~ _/) ~~~~ _/) ~~~~ _/) ~~~~ _/) ~~i

  Tom Lafleur
• 0
  
  Israel Lot July 15, 2015 15:07

  Would it be possible to allocate the heap on EDS memory space?

• 0
  
  Mike July 19, 2015 22:39

  Israel,

  No. EDS pointers are 32 bits and regular pointers are just 16. In particular stacks cannot extend into EDS space as library functions that use pointers will not work and stacks and stacks are allocated from the heap.

   

  You can use EDS space for program arrays/structures. You may want to read http://ww1.microchip.com/downloads/en/DeviceDoc/50002071E.pdf the C Compiler Guide

   

  mike

• 0
  
  Eric Christenson August 09, 2015 22:32

  Thank you for the code, mike.

  I also vote for having SPLIM protection available as an option in my official port...along with a sample stack overflow trap handler.

   

• 0
  
  Jean-Marc Delaplace January 08, 2016 10:43

  Hi, I use a DSPIC33EP256GP504 and the port works well, but only in cooperative mode. When I try preemptive mode, the 3 tasks of my project are launched, but after two vTaskSuspend calls, no task gets the processor any more, though periodic interrupts still fire, calling xTaskResumeFromISR(<task identifier>) repetitively. The kernel runs in the attempt of switching tasks forever, Specifically, it remains in the function portTASK_FUNCTION, because the condition :

  if( listCURRENT_LIST_LENGTH( &( pxReadyTasksLists[ tskIDLE_PRIORITY ] ) ) > ( UBaseType_t ) 1 )

  {
  taskYIELD();
  }
  else
  {
  mtCOVERAGE_TEST_MARKER();
  }

  is never met, so no yield is performed any more.

  The kernel is made of FreeRTOS V8.2.3, with the files in the folder FreeRTOSV8.2.3\FreeRTOS\Source\portable\MPLAB\PIC24_dsPIC replaced by the two files of the port here.

  Beside this, in MPLAB-X V3.05, the FreeRTOS viewer plugin version 2.3 shows the task states, but the only states shown are Ready, Blocked, Suspended and Deleted. No task is ever shown in the Running state, even at the very beginning where all three tasks run for one loop each.

  Note : the caption of the Viewer says : FreeRTOS Kernel 5.02 to 8.0.0. Is 8.2.3 different?

  What can be wrong?

• 0
  
  Mike January 09, 2016 14:09

  @Jean-Marc "What can be wrong?"

  Sadly, many, many things!

  At first glance it seems likely that the interrupt assignments/task priorities  are wrong, in particular this port does NOT allow nested interrupts. only interrupts at configKERNEL_INTERRUPT_PRIORITY may call a FreeRTOS function and then only the "xxxfFromISR" versions.

  I am afraid I don't use MPLAB so I can't comment on the debug tools.

  Since Tom (above) managed to get 8.2.0 working, I would first check to see if there are any changes to the official PIC port between 8.2.0 and 8.2.3. If there are not any changes it is unlikely that the port has a problem, but it wouldn't be the first (second, third... ) time I was wrong! - or you could just try 8.2.0 to be sure.

  Unfortunately, my projects still use FreeRTOS 7.5.3 (it's a bitch when stuff just works!) and briefly tested 8.2 a year ago, not to mention I use a different port ...

  I am happy to try to help, but I have to warn you that I will be "gone sailing" (literally) for the last 2 weeks of January

  mike

• 0
  
  Jean-Marc Delaplace January 11, 2016 09:50

  Mike,

  My project has nested interrupts, but only for those that do not call the kernel functions. Those that call kernel functions, have interrupt priority 1 (same as Kernel) and only the "xxxfFromISR" are used there.

  Actually, about 6 months ago, I used the only port available for DSPIC33 (I do not remember the version, probably 8.2.0), which was for dsPIC33F version only. I then altered the assembler code in the stack initialization and task switching functions to take into account the different core registers of the dsPIC33E. It worked correctly, but again only in cooperative mode. I then supposed my changes to the port were wrong is some way, and waited for a dedicated port to be published.

  When I updated the project last week using version 5.2.3 and your port (thank you for its conciseness), I hoped that this issue would be overcome. To my dismay, it is not. I would like to know who, among the users of the dsPIC port, use it in preemptive mode, to attempt to figure out what can be wrong in my implementation.

  JM

• 0
  
  Mike January 11, 2016 14:41

  JM,

  I think most people who use this port use preemptive mode, and certainly Tom Lafluer has. The port that I use actually allows nested interrupts in the kernel, but is the same basic port and I use it with lots of interrupts.

  However,  only swissembeded has ever reported using ANY dsPIC (i.e. any DSP features), unfortunately he never reported getting it working). I have got dsp features working, but only in limited testing and requires additions to configTICK_INTERRUPT_HANDLER() (see https://www.google.com/url?q=http://www.freertos.org/FreeRTOS_Support_Forum_Archive/February_2015/freertos_PIC_16-bit_port_5bd3a3b3j.html&sa=U&ved=0ahUKEwju8Iqb7KHKAhVU5WMKHTNNDioQFggIMAE&client=internal-uds-cse&usg=AFQjCNGCqFoSwgL5gIfW49srHQPFtFqMhA).

  If you are not using any DSP features, or the new "fractional" arithmetic added to the latest C compiler then I suspect this problem is due to a misunderstanding of FreeRTOS, in particular I wonder why you are using vSuspend. I would suggest you post in the regular forum describing (briefly) your three tasks, how they communicate/synchronize and PM me (dragonflight1) so I know to look for it.

  Having a problem moving from cooperative to premptive is usually(often?) due to a hidden critical section or an unforeseen ordering of messaging/synchronization calls resulting in deadlock.

  Your code snippet is part of the IDLE task, which implies there are no other tasks ready (as you have observed) at a higher priority and the code is checking if there are any other tasks ready at tskIDLE_PRIORITY

  mike

  PS I am not trying to fob you off on the general forum, but they know much more about FreeRTOS than I do and I would like to keep this post specific to port issues - which I hope after 2 years are all ironed out :)

   

• 0
  
  Mike January 18, 2016 17:57

  Israel,

  This information may be too late for you but my response to

   

  Would it be possible to allocate the heap on EDS memory space?

   

  was perhaps technically correct (Hey, don't like to admit I was wrong!!!),but  there is away to use the extra 16K in the EP512, at least some of it.

  I have been playing around (not successfully) with EDS pointer and realized how to use the extra memory without EDS pointers by using the "-mconst-in-data" and the "-wL,-no-local-stack" options. I need to warn you ahead of time that I went a different way with the project and it did not use FreeRTOS, but remembering you had asked the question I at least tested it and it seemed to work - YMMV.

  This option puts all constants in ram and sets PSV (DSRPG, DSWPG) to 1, so you have 16-bit pointer access for all ram (up to 60K), but of course lose the space occupied by the constants, in my case that was about 4K - so worth it for the 512 part, but not for the 256 part

  mike

   

• 0
  
  Mike February 12, 2016 15:07

  JM,

  I'm back, and I was wondering if you had solved your problem? I didn't see anything in the forums

  mike

• 0
  
  Mike February 12, 2016 15:28

  JM,

  Sorry I did bad searches.

  I was impressed that Richard offered to look at the code, disappointed that he gave up so quickly. If you like to send me the code I will look at it - no promises!

  I knew the names were different here (as opposed to the regular forum, but I incorrectly assumed there was a PM here. I'm dragonflight1 on the forum. PM me and we can discuss it

   

  mike

• 0
  
  Jean-Marc Delaplace February 18, 2016 16:04

  Mike,

  thanks for taking care of me.

  I made a contribution in the Source forge forum, https://sourceforge.net/p/freertos/discussion/382005/thread/fbf8a438/?limit=25#4a9d

  after a while they stopped exchanging with me.

  So far, the state of the problem is the same : the preemptive mode does not allow some tasks to run whereas they are ready, or they do but at the wrong rate.

  I have attached a zip of a project that shows this wrong behaviour. If you have a chance to test it, please tell me how it behaves with you.

  This project uses a dsPIC33EP256GP504.

  No special hardware is required to have this code run, but a 8 MHz crystal.

  I test this project using MPLAB-X 3.05 with the XC16 compiler version 1.24.

  The global defines include "__dsPIC33E__"

  These files are taken from my project, from which I have wiped most of the processing to keep only the initialisation and the tasks, which only increment a counter at each cycle.

   

  In the main.c file, you will see that I create 3 tasks. One of them, TaskDecodageCAN, performs some initialisation then kills itself.

  Two tasks are remaining, one in file Chauffage.c, the other in file Mecanique.c.

   

  The task Chauffage uses a vTaskDelayUntil so that it runs once a second, thus the counter shows 10 after 10 seconds of execution.

   

  The task Mecanique waits for a ulTaskNotifyTake to succeed, which should occur 500 times per second.

   

  The notification is produced as follows :

  a) the A/D converter is triggered by a timer, and scans 4 analog inputs. Every four conversions, the DMA triggers an interrupt, which occurs every 20 microseconds. This interrupt calls the ISR called InterruptionMesureMecanique (here, I have deleted the data processing that occurs at each interrupt). Every 100 times it is called, data is available. The ISR sets then the IC1IF flag, to make believe an Input Capture has occurred. This ISR has a priority of 7.

  b) the IC1 interrupt calls the ISR InterruptionIC1, which executes vTaskNotifyGiveFromISR. This ISR has a priority of 1.

   

  This construct is complex, but it guarantees that the fast processing is performed with a high priority, then once every 100 calls it defers the calling of vTaskNotifyGiveFromISR to another interrupt which priority meets the requirement of priority required to call kernel functions from interrupts.

   

  Now, I have tested this code in debug mode.

  If I set configUSE_PREEMPTION to zero, the application works well

  After a 10 second execution, the counter of the Chauffage task shows 10, and the counter of Mecanique shows 5000 (approximately).

   

  If I set configUSE_PREEMPTION to 1, after 10 s or execution both counter are at 10.

   

  In the original project, none of the tasks would run after having done one or two cycles each. I do not know why this different behaviour, but I assume that it must be the same cause, that once fixed will allow the kernel to run correctly in preemptive mode.

  Thanks in advance for your help.

   

• 0
  
  Jean-Marc Delaplace March 01, 2016 08:58

  Following mike's advice, I have added a call to portYield() after vTaskNotifyGiveFromISR and my application works as expected.

  I had expected this to be implicitly performed within the vTaskNotifyGiveFromISR body but since it is not, the explicit call to portYield is required.

  Thanks mike !

• 0
  
  BBB December 05, 2016 15:37

  For all you guys looking into this longer then me, why can't the GIE bit in INTCON2 be used to manage nested interrupts? So uxPortSetInterruptMaskFromISR would be something like:

  clear GIE bit (might need a nop here)
  save IPL bits to uxSavedStatusRegister
  set IPL bits to configMAX_SYSCALL_INTERRUPT_PRIORITY
  set GIE bit
  return uxSavedStatusRegister

  I have done some searching for any discussions about the GIE bit and why there might be problems doing something like this but haven't found anything. So sorry if this has already been clarified somewhere else. 

   

   

• 0
  
  Mike December 07, 2016 23:43

  @BBB

  First I would appreciate it if you started a thread in the general forum and posted a link here if you want to discuss this. I will be happy to discuss this with you there (but a warning - I am away for a week, but will reply when I return). As a side note I don't read the forums regularly at the moment so this was the easy way to get my attention!

  That said I don't understand your comment, you may want to read

  https://sourceforge.net/p/freertos/discussion/382005/thread/a350dbe2

  and the thread it references.

  I do have a version of this port which does nested interrupts (which is the version I use), but I have avoided muddying the waters as I have been trying to get this "simple" version adopted as the supported version.

  as suggested in the forums - not sure where - it is almost always possible to get around nested interrupts by using a second "unused" PIC interrupt to signal a process

  i.e.

  HighPriorityInterrupt() {
         ....
         _XXXIF = 1;       // some unused interrupt at low priority
  }
  XXXXInterrupt() {
         _XXXIF = 0;
                  vTaskNotifyGiveFromISR(...);
  }

  mike

• 0
  
  Victor Wheeler January 21, 2017 21:03

  Hello, Mike!

  In your PORT.C file you have this line:

  UBaseType_t uxCriticalNesting = 0xef;

  initializing that variable to 0xEF.

  Yet this value is used to increment and decrement inside portENTER_CRITICAL() and portEXIT_CRITICAL(), and portEXIT_CRITICAL() re-enables interrupts only when the value has returned to 0 again.

  In my current project I'm not using portENTER_CRITICAL() anywhere, but I have needed to in past projects, and it seems if I ever did, that I would permanently shut off interrupts at or below configKERNEL_INTERRUPT_PRIORITY if I ever used it, which would stop the application TICK, and all my interrupts that call FreeRTOS API functions.  So this seems like an error to me.

  Can you help me understand why 'uxCriticalNesting' is being initialized to 0xEF?

  Kind regards,

  Vic

• 0
  
  Victor Wheeler January 21, 2017 22:18

  (P.S.  I just realized that it is indeed used all over the place via taskENTER_CRITICAL().)

• 0
  
  Victor Wheeler January 21, 2017 23:13

  Hi, Mike!

  Well, I figured it out.  The answer is that if it has an initialization value it is only for debugging, because when each task (and its stack) is initialized, that the value for uxCriticalNesting is pushed onto each task's stack as the 2nd-to-last item.  So the value 0xEF only lasts until the scheduler starts.  When the scheduler starts, the contents of the global variable uxCriticalNesting is replaced from that value in each task's stack as each task is swapped in.

  Kind regards,

  Vic