problem with binary semaphore

richpainter wrote on Friday, June 20, 2008:

I am running 5.0.0 with Microchip MPLAB 8.10 and C30 3.10 with Real Ice for a dspic33fj.

In my main() I create several binary semaphores PRIOR to creating any tasks and PRIOR to starting the scheduler.

When I invoke the xSemaphoreTake(my_sema, portMAX_DELAY) I get a stack error trap and since I have a simple handler with a halt in it I get control back to MPLAB’s debugger.

1) I don’t understand why this is happening at this early stage.

2) If I single step into the xSemaphoreTake() a different strange result happens… drilling down it finally reaches vPortEnterCritical() and when it steps to portDisableInterrupts() MPLAB HANGS! ALL of the open MPLAB windows go "not responding" and the hour glass appears.

Does anyone have any idea about these 2 problems?


picmeup wrote on Friday, June 20, 2008:

C30 3.10 has bugs. It dont work. Use older version.

rtel wrote on Friday, June 20, 2008:

I’m not sure about C30 V3.10, but V3.10b definitely contains bugs that will prevent it from being used with (and other applications).  I have a work around that will make it work provided no optimisation is used, if you send me an email to r _dot_ barry (at) I can send you the necessary files.

Microchip are aware of the issue and working on a fix.


richpainter wrote on Friday, June 20, 2008:

I sent an e.mail at the time of my post requesting the asm file mentioned.

Q1. So, are you saying that the problem I describe here is known to be attributed to this bug?

Q2. When I perform with this same configuration of versions a queue create and then only after starting the scheduler, doing a "take" works fine. So is this still the same problem you are attributing to?

Q3. Why would it work in one case and not the other?


rtel wrote on Friday, June 20, 2008:

> I sent an e.mail at the time of my post requesting the asm
> file mentioned.

I sent the file as soon as your email arrived.  Did you receive it?

> Q1. So, are you saying that the problem I describe here is
> known to be attributed to this bug?

No - not at all.  Without having a play with your project I could not say anything for sure.  However what is known for sure is that the compiler contains bugs that prevent the standard demos from running (without the workaround in place) so your problems *could* be caused by this.  The bug is quite serious in that it clobbers its own frame pointer when entering a function, so this can have very unpredictable results.

It also could just be a genuine stack overflow.

> Q2. When I perform with this same configuration of versions a
> queue create and then only after starting the scheduler,
> doing a "take" works fine. So is this still the same problem
> you are attributing to?

Reading your original post again - are you attempting to block on a semaphore take before the scheduler is started?  This will definitely not work, compiler bug or not.  Its not clear, you say you are creating the semaphore before the scheduler is started, but not when you call xSemaphoreTake(), before or after the scheduler is started.  You should be able to call the function provided the code does not attempt to block.

> Q3. Why would it work in one case and not the other?

Should not make any difference.


richpainter wrote on Friday, June 20, 2008:

I received the asm file and implemented your recommendations. It did NOT cure the problem I am having as written in this thread.

I originally stated "In my main() I create several binary semaphores PRIOR to creating any tasks and PRIOR to starting the scheduler." The creation of the semaphore is PRIOR to starting the scheduler.

I then call xSemaphoreTake(my_sema, portMAX_DELAY) also PRIOR to the start of the scheduler.

I assumed that since no RTOS tasks are created yet that the xSemaphoreTake would "pass thru granting" in this context.

This sema is used in code that is called PRIOR to the start of the scheduler and is also required for multiple tasks to use the semaphore once the scheduler is started from created tasks.

Are you saying xSemaphoreTake() cannot be called PRIOR to the starting of the scheduler?

If so, how does one make generalized code containing sema and mutexes that will work PRIOR to the star of the scheduler and also AFTER it is started?

If this is OK to call in this context then the stack problem cure that was expected to fix the problem did not work. I have a LOT of stack space allocated so I don’t think it is an exhaustion issue.



richpainter wrote on Friday, June 20, 2008:

Just to add more detail here…

doing the create and xSemaphoreTake PRIOR to the start of the scheduler and stepping down thru the xSemaphoreTake I reach this code in (modified for addition of the asm function) port.c:

void vPortEnterCritical( void )

The instant I single step with the MPLAB debugger on the Real ICE into this function MPLAB freezes up. All the windows go "Not responding". I have to kill the task and start over.

I don’t think this should happen. Even if there is a freeRTOS problem it should not cause the MPLAB to hang.

Am I wrong here?

If I just let the code run from the call to xSemaphoreTake it causes my stack trap to hit. But as I said before I have over 1kb of stack and very little stack resident stuff up to the point this xSemaphoreTake  is called.

I don’t know how to report this to Microchip since they are overloaded with bugs with both the new MPLAB 8.10 and the C30 gcc problems.

Any suggestions would be appreciated.

rtel wrote on Saturday, June 21, 2008:

I have:

+ Taken the latest V5.0.2 release.
+ Turned off optimisation.
+ Turned off the “omit frame pointer” option.  (I would not expect the demo to run like this, but have done this so the compiler bugs don’t get in the way).
+ Added the code below to the top of main().

int main( void )
xSemaphoreHandle xSemaphore = NULL;

____xTaskCreate( vCheckTask, ( signed portCHAR * ) "Check", mainCHECK_TAKS_STACK_SIZE, NULL, mainCHECK_TASK_PRIORITY, NULL );

____vSemaphoreCreateBinary( xSemaphore );

____if( xSemaphore != NULL )
________xSemaphoreTake( xSemaphore, portMAX_DELAY );

Both with and without the call to xTaskCreate() I was able to successfully step through the code.

It does not make sense to state a block time of portMAX_DELAY when the scheduler is not running, it would be better to have a block time of 0, but having stepped through the code I would say it does not actually make any difference in this case.

Have I done anything different to you?


richpainter wrote on Sunday, June 22, 2008:

The only material difference that I can see is that I’m on FreeRTOS 5.0.0 and you are using 5.0.2.

Per your instructions, I commented out a section of port.c and added portasm_PIC24.S to the mix. I have -O0 optimization and have removed any -fomit-frame-pointer in BOTH versions of the RTOS projects.

I can’t get 5.0.2 to link. I have the RTOS in a subdirectory to my application. If I replace the subdirectory with one from 5.0.2 I get the following link error:
mplab c30 310\bin\bin\pic30-coff-ld.exe Error: A heap is required

It compiles just fine, has the same gcc options and linker options. When using 5.0.0 I never entered into MPLAB link options that specify a heap. I did not do so with 5.0.2 either.

So I can’t figure out why this links OK with 5.0.0 and not with 5.0.2.

If I could get this running I could get back to this sema issue and answer your previously posted question.

As it is now neither 5.0.0 nor 5.0.2 will run but for different reasons.


woops_ wrote on Sunday, June 22, 2008:

Out of heap_1.c heap_2.c and heap_3.c, heap_3.c is the only one that requires you to setup a heap using the linker script. Did you include heap_3.c in your project by mistake?

richpainter wrote on Sunday, June 22, 2008:

My FreeRTOSConfig.h are identical between 5.0.0 and 5.0.2
I build the FreeRTOS code as a library and link it to my project as a library. This worked fine with 5.0.0.

I use heap_1.c (I thought). All 3 heap_N.c are included in each of the 5.0.0 and 5.0.2 libs.

Now that you raise the question I don’t recall how I originally specified which to use. I thought I had set something in a .h file which selected which to use. I guess I’m wrong. I don’t understand why the 5.0.0 didn’t have this complaint because the libs have the same content file list (except as noted below).

I will remove the other 2 heap_N.c and see if this cures it…

FreeRTOS MPLAB project search for "heap_3"…

C:\D\src\Microchip\TekVet\Ver2\FreeRTOS\src\heap_1.c:68:  * See heap_2.c and heap_3.c for alternative implementations, and the memory
C:\D\src\Microchip\TekVet\Ver2\FreeRTOS\src\heap_1.c:141:     /* Memory cannot be freed using this scheme.  See heap_2.c and heap_3.c
Search complete. 2 matches found.

It did NOT cure it. I currently only have heap1.c in the lib yet the linker still complains about needing a heap. MPLAB destroys the .a on rebuild so it can’t be due to those other heap_N.c obj hanging around.

I did an ar -tv…

rw-rw-rw- 0/0 287171 Jun 22 12:59 2008 tasks.o
rw-rw-rw- 0/0 271596 Jun 22 12:59 2008 croutine.o
rw-rw-rw- 0/0 266693 Jun 22 12:59 2008 list.o
rw-rw-rw- 0/0 267535 Jun 22 12:59 2008 port.o
rw-rw-rw- 0/0 277820 Jun 22 12:59 2008 queue.o
rw-rw-rw- 0/0 265843 Jun 22 12:59 2008 heap_1.o
rw-rw-rw- 0/0   2170 Jun 22 12:59 2008 portasm_PIC24.o

I’m still confused why this is happening. I did a file compare of the 5.0.0 and 5.0.2 and there are not many differences, certainly doesn’t explain this. The change I made over the distribution of 5.0.2 was to comment out vPortYield() from port.c and include postasm_pic24.s.

No rtos-specific files are specified in my top-level project, only the reference to the rtos.a which is built (and contents listed above).

Any other suggestions?


rtel wrote on Sunday, June 22, 2008:

Can you zip up your project and send it to me?  Use the address you used last time, not the SourceForge address as this will strip off the attachment.


richpainter wrote on Sunday, June 22, 2008:

In the mean time, I have looked closely at what MPLAB does and I think the heap problem is due to a deficiency in MPLAB in the way it includes/builds the libs. From the 5.0.2 perspective, even though only heap_1.c is in the MPLAB project (after I removed the project entries for heap_2.c and heap_3.c) the .o for them were still around. MPLAB was still getting all the heap modules in thus having the conflict with heap_3.c not getting the heap that it needed.

After seeing this I recall I had seen this some months back on another MPLAB project where I had 2 subdirectories with different version of a lib in them and switched the directory file names and it didn’t load the lib correctly just like this.

I always specify for my MPLAB project entries project relative file locations. I don’t know what is causing this bug but it is an insidious problem.

Now I can link 5.0.2. However, the tasks don’t seem to run correctly at all with 5.0.2. Even if I take all the sema create and take out that I had in it the tasks just dont run. If I swap 5.0.0 back in the tasks run OK.

This very well may be C30 3.10 and that I have hit upon something that allowed FreeRTOS to work for 5.0.0 but not 5.0.2 even with the -O0 and port.c/postasm_pic24.s change.

I read from others that C30 3.10 won’t work at all but I did have it running in a fashion before trying to use the sema.

You said you were successful with C30 3.10 so I kept using it.

I’m wondering now if I should go all the way back to C30 3.01 which I am using on another project that has not been moved to the new C30 3.10…

I am still confused about the fact that my 5.0.0 project includes all the heap modules in the rtos lib yet it doesn’t have this problem… but maybe that is why the sema does not work for 5.0.0…

There are so many variables to this it is very hard to isolate what the problem is. I have many, many years of RTOS experience but just started using FreeRTOS and I have not yet learned enough about its inner working to try and debug this kind of a problem, mostly since I’m under a deadline and don’t have time to do so.

If you still want me to send you my project then let me know and to what extent (the RTOS lib for sure, but Microchip TCPIP lib and my app?).


richpainter wrote on Monday, June 23, 2008:

As I had said 5.0.0 worked in a manner but it will NOT work with the mod to port.c and portasm_PIC24.S.

I went back to it and pulled these out (restored port.c and took portasm_PIC24.S out of the lib) and removed all the sema stuff. I have not tried the sema stuff again in this mode but I will and report back.


richpainter wrote on Tuesday, July 01, 2008:

I am back to working on this again trying to get a binary semaphore to work prior to the start of the scheduler.

I am using freertos 5.0.0, MPLAB 8.10, C30 3.10.

When I call the xSemaphoreTake I get an address error trap. I do not return from the call.

I discovered a bug in my code whereby I cleared a structure that had contained the initialized sema object returned from the create.

Since I tested for the error return of the xSemaphoreTake I expected that it would catch stuff like this. Not so.

I corrected my error and it now works OK.

I would suggest that the xSemaphoreTake and Give check for a valid sema argument passed to it and return an error to the caller like all good systems functions.

thanks for your patience,