Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




Loading

Task hangs semaphore-protected share resource

Posted by Nobody/Anonymous on May 30, 2005
Hello everyone,

I have a problem that I cannot put my finger behind (I am relatively new to FreeRTOS).

My example program has two tasks, plus the idle task, with the preemtive scheduler (it runs on an LPC2138, it is compiled with GCC). One high-priority task sits in a loop waiting for something to do. As there is nothing to do (yet), the task just sits in a loop calling "vTaskDelay(10)". No trouble here.

The other (low priority) task runs in a loop doing continous transfers over an I2C protocol, in small bursts (but no delay between the bursts). As the I2C interface is intended to be shared between several tasks, I folded the function that does a single burst transfer inside xSemaphoreTake() and xSemaphoreGive() calls.

This runs for several hundreds or thousands of "bursts", and then everything stops. xSemaphoreTake() does not time-out either. I put logging (over a serial line) in the code to verify whether xSemaphoreTake() or xSemaphoreGive() hangs, but then the problem "magically" goes away (logging slows things down).

I replaced the semaphore with taskENTER_CRITICAL() and taskEXIT_CRITICAL(), and everything works again.

So... just use a critical section, one would say. However, the high-priority task does not use I2C and it would be unfortunate if it were "held up" by the low-priority task(s).

Oh, another thing that I tested was using the semaphore-protected I2C protocol without ever starting the scheduler (and without logging). This gives no problem either. At first sight, it appears that particular sequence of grabbing/freeing the semaphore and the scheduler causes the task to be blocked, especially if the "take/give" sequence is very quick.

Any help on this is greatly appreciated. Thanks in advance,
Thiadmer

RE: Task hangs semaphore-protected share resource

Posted by Richard on May 30, 2005
> As the I2C interface is intended to be shared
> between several tasks

As a slight aside - depending on your application it can be a nice way to share a peripheral to have one task that manages the peripheral. This task just takes messages that need transmission from a queue and transmits them on the i2c. No other task is allowed to access the hardware. If another task wants to use the i2c is send the message on a queue to the manger task - which removes it from the queue and sends it. It does not matter then how many tasks send messages to the manager task, no mutual exclusion is required.

>This runs for several hundreds or thousands
>of "bursts", and then everything stops.
>xSemaphoreTake() does not time-out either.

Does the high priority task still run even when the i2c task has stopped - or does everything hang?

If everything hangs the most likely cause is a memory corruption somewhere - you might want to try increasing the stack sizes a bit.

Does your i2c interface use interrupts or poll?


> So... just use a critical section, one would say

I wouldn't :-) Whenever there is unexplained behaviour it is always best to get to the cause rather than just find a work around. Otherwise it will always come back an bite you.


The WizNET demo application uses an interrupt driven i2c interface on an LPC2000.

RE: Task hangs semaphore-protected share reso

Posted by Nobody/Anonymous on May 31, 2005
This turns out to be a hardware error. The slave in the I2C protocol does not behave as it should (in keeping the SCL low while processing). This apparently confuses the LPC2000 as much as needing a power cycle to recover. The occurence of the error is heavily timing dependent, which is why critical sections gave a so much different result from semaphores.

The flaky chip in question is the microchip MPC23016 (I/O expander). Our temporal solution is to run the I2C protocol at 50 kHz instead of 400 kHz.

Thanks a lot for thinking with us.
Kind regards,
Thiadmer


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists