ChibiOS Free Embedded RTOS

Hi Giovanni,
We have implemented an LCD driver with Mutex, and also a RTC Callback (in main.c) at 1 second interval. The callback calculates the current H:M:S and displays it on the LCD. All draw functions are enclosed with
chMtxLock(&LCDD.mutex); <code> chMtxUnlock();

We have several other source.c that do graphic functions, and we found that it was necessary to
use
extern void realTimeClockCallback;

so we can call ...

rtcSetCallback(&RTCD1,NULL);

<lcd draw code>

rtcSetCallback(&RTCD1,&realTimeClockCallback);

otherwise there would be lock up issues.

So here's the problem. 2.40 runs for about 20 mins or so, all the graphics work (including multiple draw threads) just fine, and then it locks up. If I remove all rtcSetCallback(&RTCD1,&realTimeClockCallback); calls, then it all runs with no obvious problems (e.g. 3 hours cycling through the graphics tests).

My theory at present is that the rtcSetCallback is in some way chewing up memory, and once its all used, we get lock up. I've poked around in the code at length, and don't see anything obvious.

Can you suggest what might be happening? Is there a way to track the memory usage, say output to SD1? We build with
__main_stack_size__ = 0x4000;
__process_stack_size__ = 0x4000;

regards
SD

Hi rallysjd,

rallysjd wrote: The callback calculates the current H:M:S and displays it on the LCD. All draw functions are enclosed with
chMtxLock(&LCDD.mutex); <code> chMtxUnlock();

Calling heavy functions (H:M:S calculations) in callbacks is very bad idea. Try to rewrite code. Use callback just to signalling (through semaphores for example) waiting thread with calculation functions.
What means lockup in you case? Can you break program after "lockup" and investigate memory usage with Eclipse debugging plugin?
It would be good to see your mcuconf.h file.

barthess wrote:... Use callback just to signalling (through semaphores for example) waiting thread with calculation functions.

Thanks. I set up a binary semaphore and a H:M:S calc/display thread to wait on it. The RTC callback just signals the semaphore. Works perfectly now.

SD

rallysjd wrote:Works perfectly now.SD

Well, almost. I changed the BinarySemaphore to a Semaphore. The intent was to pass the RTCcallback event into the waiting thread via the s_cnt value.

This does not work for me at present, and the Semaphore is not passed to the waiting thread at all. I don't see why using a BinarySemaphore works and a Semaphore does not. Do I need to set the wait thread in the Semaphore ThreadList item?

SD

If you want not only sync the thread but also want to pass some data to it than try to use MailBoxes. Any way, I am more hardware driver developer. Giovanni can better explain what happens in your case.

Counter semaphores can be signaled without an upper bound while binary semaphores can only taken or not taken, there is a difference if in you use case the number of "signal" operation can be greater than the number of "wait" operations.

Also verify the initialization, in counter semaphores the equivalen of "taken" is the value zero.

I can't help more than this without seeing the code.

Anyway, barthess is correct in suggesting that mailboxes can be preferable if you have to send a message between the interrupt handler and the waiting thread.

Giovanni