• State Accepted Answer
  • Locked Locked
  • Replies 2 replies
  • Subscribers 350 subscribers
  • Views 1791 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Why does the following code not blinking the built-in LED (A_5) on an F103RB board when using the CIM-RTOS2 API. The same code works when using the older CIM-RTOS API. There are no compilation errors: no errors no warning when compiling. The code does work

HendersonH 

/*----------------------------------------------------------------------------
 * CMSIS-RTOS 'main' function template
 *---------------------------------------------------------------------------*/
 
#include "RTE_Components.h"
#include  CMSIS_device_header
#include "cmsis_os2.h"
 
void GPIOInit(void);
void LEDOn(void);
void LEDOff(void);
 
/*----------------------------------------------------------------------------
 * Application main thread
 *---------------------------------------------------------------------------*/
__NO_RETURN static void app_main (void *argument) {
  (void)argument;
  // ...
  for (;;) 
	{
		LEDOn() ;
		osDelay(500);
		LEDOff();
		osDelay(500);
	}
}
 
int main (void) {
  osKernelInitialize();                 // Initialize CMSIS-RTOS
  // System Initialization
  SystemCoreClockUpdate();
	GPIOInit();
  // ...
  osThreadNew(app_main, NULL, NULL);    // Create application main thread
  osKernelStart();                      // Start thread execution
  for (;;) { osDelay(20); }
}


void GPIOInit(void)
{
	//enable GPIOA
	RCC->APB2ENR |= RCC_APB2ENR_IOPAEN;
	//PA_5 - output, push pull (green Led)
	GPIOA->CRL |= GPIO_CRL_MODE5_0 | GPIO_CRL_MODE5_1;
	GPIOA->CRL &= ~GPIO_CRL_CNF;
}


void LEDOn(void)
{
	//turn on A_5
	GPIOA->BSRR |= GPIO_BSRR_BS5;
}
	
void LEDOff(void)
{
	//turn off A_5
	GPIOA->BSRR |= GPIO_BSRR_BR5; 
}

Parents
  • 0

    You don't mention the RTOS2 implementation explicitly in your post, but I shall guess it's RTX(5).  I have seen osThreadNew fail, and return NULL, in cases where the values in RTX_Config.h are mutually inconsistent.  One example is requesting a thread stack size that is larger than your overall memory size reserved for RTX as a whole (OS_DYNAMIC_MEM_SIZE).

    My hunch is, if you were to inspect the return value of your osThreadNew() call, that you would see a NULL.  The thread will never be started, hence your LED logic is never firing.

    Furthermore, I don't think that your for loop AFTER the osThreadNew call is ever going to run either.  osKernelStart doesn't return to the caller. My guess is that your system is stuck in the idlerThread, the default (weak) version of which is just a while-1.  See RTX_Config.c in the RTX sources.

Reply
  • 0

    You don't mention the RTOS2 implementation explicitly in your post, but I shall guess it's RTX(5).  I have seen osThreadNew fail, and return NULL, in cases where the values in RTX_Config.h are mutually inconsistent.  One example is requesting a thread stack size that is larger than your overall memory size reserved for RTX as a whole (OS_DYNAMIC_MEM_SIZE).

    My hunch is, if you were to inspect the return value of your osThreadNew() call, that you would see a NULL.  The thread will never be started, hence your LED logic is never firing.

    Furthermore, I don't think that your for loop AFTER the osThreadNew call is ever going to run either.  osKernelStart doesn't return to the caller. My guess is that your system is stuck in the idlerThread, the default (weak) version of which is just a while-1.  See RTX_Config.c in the RTX sources.

Children