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

Weird issue with PSoC5LP porting and sleep mode

Posted by maiorfi on February 19, 2014

Hi everybody. We are experimenting a big issue on FreRTOS porting for Cypress PSoC5LP in a firmware using power management features with both 1 and 2 configUSETICKLESSIDLE modes.

To allow easier diagnostics, we just prepared a simple demo targeted to Cypress evaluation board for PSoC5LP microcontroller (CY8CKIT-050). It should run (with possible exception concerning on-board led pinout) on any board equipped with microcontrollers of same family (e.g. freesoc board). Demo project (for PSoC Creator 3 with GCC toolchain) is located at https://dl.dropboxusercontent.com/u/7414592/ELock/ELock_Firmware.cywrk.Archive01.zip

In our firmware we have only one simple task, running a never-ending cycle inside which it just toggles a led.

Setting configUSETICKLESSIDLE to 1, we defined configPRESLEEPPROCESSING and configPOSTSLEEPPROCESSING as follows:

#define configPRE_SLEEP_PROCESSING( xModifiableIdleTime ) enterSleepMode(xModifiableIdleTime)
#define configPOST_SLEEP_PROCESSING(xModifiableIdleTime) exitFromSleepMode(xModifiableIdleTime)

where such functions are defined as follows:

#include <project.h>

#include "FreeRTOS.h"
#include "task.h"

static portTickType s_actualIdleTicks = (1<<SleepTimer_INTERVAL)/(1000/configTICK_RATE_HZ);

void enterSleepMode(uint32 xExpectedModifiableIdleTime)
{
	xExpectedModifiableIdleTime=0;

	CyPmSaveClocks();

	CyPmSleep(PM_SLEEP_TIME_NONE,PM_SLEEP_SRC_CTW);
}

void exitFromSleepMode(uint32 xExpectedIdleTime)
{
	CyPmRestoreClocks();

	vTaskStepTick(s_actualIdleTicks);
}

Here, we refer to a SleepTimer "creator" component configured in such a way to raise interrupt at awake time (as explained in Cypress application note) whose isr is defined as:

CY_ISR(WakeupIsr)
{
    /***************************************************************************
    * This function must always be called (when the Sleep Timer's interrupt
    * is disabled or enabled) after wake up to clear the ctw_int status bit.
    * It is required to call SleepTimer_GetStatus() within 1 ms (1 clock cycle
    * of the ILO) after CTW event occurred.
    ***************************************************************************/
    SleepTimer_GetStatus();
}

we set up such isr as follows:

int main()
{
	// Inizializzazione FreeRTOS
    setupRTOS();

	isr_SleepTimer_StartEx(WakeupIsr);
	SleepTimer_Start();

    /* Place your initialization/startup code here (e.g. MyInst_Start()) */
	vStartSimpleTask(tskIDLE_PRIORITY+5);

	// Avvio del RTOS
	vTaskStartScheduler();

    CyGlobalIntEnable;

	for(;;)
    {
        /* Place your application code here. */
    }
}

where setupRTOS() is standard initialization of vector table handlers provided by FreeRTOS "boilerplate" code:

void setupRTOS()
{
	/* Port layer functions that need to be copied into the vector table. */
	extern void xPortPendSVHandler( void );
	extern void xPortSysTickHandler( void );
	extern void vPortSVCHandler( void );
	extern cyisraddress CyRamVectors[];

	/* Install the OS Interrupt Handlers. */
	CyRamVectors[ 11 ] = ( cyisraddress ) vPortSVCHandler;
	CyRamVectors[ 14 ] = ( cyisraddress ) xPortPendSVHandler;
	CyRamVectors[ 15 ] = ( cyisraddress ) xPortSysTickHandler;

	/* Start-up the peripherals. */

}

Our (only and simple) task definition is:

static portTASK_FUNCTION( vSimpleTask, pvParameters )
    {
    	portTickType xLastTime;

    	/* The parameters are not used. */
    	( void ) pvParameters;

    	/* We need to initialise xLastFlashTime prior to the first call to 
    	vTaskDelayUntil(). */
    	xLastTime = xTaskGetTickCount();

    	uint8 toggler=1;

    	for(;;)
    	{
    		LED_Write(toggler);

    		toggler=!toggler;

    		// Wait for 1 sec...
    		vTaskDelayUntil( &xLastTime, configTICK_RATE_HZ );
    	}
}

Now for the weird issue: The strange issue we experiment is that led flashes with a absolutely random period! Often it seems blocked, but waiting for 10-15 secs we can see the led toggling! Also, it is non so infrequent to look at very quick (roughly .1 secs) togglings.

What could be the cause of such non-deterministic behavior? What should be the "right way" to manage power management in FreeRTOS applications targeted to PSoC5LP?

Thanks!


Weird issue with PSoC5LP porting and sleep mode

Posted by rtel on February 19, 2014

I'm not going to be able to help with anything chip specific, but before getting to the chip specific stuff some basic questions:

1) If you set configUSETICKLESSIDLE to 0 and leave everything else the same, is the LED blinking as you would expect?

2) If the answer to (1) above is yes, if you set configUSETICKLESSIDLE to 1 but take out the pre and post sleep macros, is the LED blinking as you would expect?

Regards.


Weird issue with PSoC5LP porting and sleep mode

Posted by maiorfi on February 19, 2014

1) Yes 2) Yes

Thanks!


Weird issue with PSoC5LP porting and sleep mode

Posted by rtel on February 19, 2014

So the problem must be either with the use of xModifiableIdleTime, which is the parameter passed into configPRESLEEPPROCESSING(), or the use of the Cypress libraries.

Are you expecting the Cypress libraries to perform the actually sleep function? That is, call wfi or wfe? If so then you must set xModifiableIdleTime to zero so FreeRTOS does not also call wfi.

In enterSleepMode() you are setting xExpectedModifiableIdleTime to zero - are you expecting that to set xModifiableIdleTime() to zero? As it is, xExpectedModifiableIdleTime is local to your enterSleepMode() function, so setting it to zero seems to be an obsolete action. If you want it to set xModifiableIdleTime() to zero then you will have to modify your configPRESLEEPPROCESSING() macro to either pass xModifiableIdleTime into enterSleepMode() by reference so it can then be set to zero, or to set xModifiableIdleTime to zero explicitly as per the following:


#define configPRE_SLEEP_PROCESSING( xModifiableIdleTime ) xModifiableIdleTime = 0; enterSleepMode();

Are you using SysTick to generate the tick interrupts?

Regards.


Weird issue with PSoC5LP porting and sleep mode

Posted by maiorfi on February 19, 2014

We tried both setting (the actual, indeed) modifiableIdleTime to zero and not doing it, with same result.

Since we didn't provide a custom vPortSetupTimerInterrupt(), we should be using SysTick as tick source.

We're using FreeRTOS 7.6.1.

Thanks.


Weird issue with PSoC5LP porting and sleep mode

Posted by maiorfi on February 19, 2014

Oh, I forgot to mention that while debugging (via SWD, by mean of evaluation board built-in debugger) everything runs as expected. Maybe debugging features prevent entering in sleep mode?


Weird issue with PSoC5LP porting and sleep mode

Posted by rtel on February 19, 2014

It does sound like there is something wrong with the inputs to the Cypress drivers, or how some hardware is managed when you wake.

You say it works when debugging, but not when you run it without the debugger? It is likely the debugger would interfere, especially if it is polling the cycle counter or some other live view variables, but I would expect it to be the other way around - that is - to work better without the debugger than with it. Still, it gives you a clue either way.

Regards.


Weird issue with PSoC5LP porting and sleep mode

Posted by maiorfi on February 19, 2014

Exactly, maybe at some level debugging subsystem simply prevents power mode changing.


Weird issue with PSoC5LP porting and sleep mode

Posted by maiorfi on February 20, 2014

Any news? Did you try to run linked firmware project in order to verify the issue?

Thank you very much.


Weird issue with PSoC5LP porting and sleep mode

Posted by rtel on February 20, 2014

Sorry - I don't have anything more to add over and above my post two above this one. It does appear to be something inside the Cypress drivers are not functioning as you think they do, or are not being re-initialised/reset/updated when you leave sleep. Plus the debugger interference issue will be a hardware effect, not a FreeRTOS effect.

Regards.


[ 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