Hi All

I'm trying to run the demo for FreeRTOS (v 7.4.2) on the EFM32 Development kit. I've opened the workspace file in the FreeRTOS/Demo/CORTEX_EFMG890F128_IAR directory and run it but nothing happens. The code gets stuck at the first instance of

while (!(usart->STATUS & USART_STATUS_TXC)) ;

that it comes across (in dvk_spi.c). I've run various blink and LCD examples from Energy Micro's Simplicity Studio and they run fine.

Any known reasons the demo would be getting stuck at this point?

That does not look like an RTOS problem, but a uart init problem. If the uart is not enabled and clocked its status register is not going to change. If nothing else the code should be updated so the while() loop will time out to prevent your code hanging there.

The demo you are using is old and probably uses old drivers, but that would not explain why something that once worked no longer works.

I imagine EFM parts will not clock the peripherals when the mcu is power up and that the clocks have to be turned on explicitly. Is the code doing that? Is there any other uart initialization that must be performed before you can use it? Maybe the uart itself must be enabled as well.

Could the revision of chip you are using need a different init sequence to the chip used to create the demo? That is something that happened when updated PIC32 parts had different uart implementations to the original part numbers. Look at the examples provided with the Studio software to see how they init the uart to compare. Report back here if anything in the demo needs updating.

Just looking at that demo (it would be a good candidate for the new super fantastic tickless idle features in FreeRTOS ;o) and it seems that all initialisation is performed by the library functions. The FreeRTOS just calls the library functions.

It took me a while to see what the SPI was being used for, but it looks like the LEDs are controlled via SPI.

Regards.

Ok so I don't really know what I'm doing but in case this is meaningful:

The examples provided by Energy Micro initialised a clock for the GPIO pins before changing their register values. I can't see this being done in the FreeRTOS demo and when the demo reaches this code (in dvk_spi.c):

  /* Configure SPI bus connect pins */
  gpio->P[2].MODEH &= ~(_GPIO_P_MODEH_MODE13_MASK);
  gpio->P[2].MODEH |= (GPIO_P_MODEH_MODE13_PUSHPULL);
  gpio->P[2].DOUT &= ~(1UL << 13);

  /* Configure SPI pins */
  gpio->P[2].MODEL &= ~(_GPIO_P_MODEL_MODE2_MASK |
                        _GPIO_P_MODEL_MODE3_MASK |
                        _GPIO_P_MODEL_MODE4_MASK |
                        _GPIO_P_MODEL_MODE5_MASK);
  gpio->P[2].MODEL |= (GPIO_P_MODEL_MODE2_PUSHPULL |
                       GPIO_P_MODEL_MODE3_PUSHPULL |
                       GPIO_P_MODEL_MODE4_PUSHPULL |
                       GPIO_P_MODEL_MODE5_PUSHPULL);
  gpio->P[2].DOUT |= (1UL << 5);

the register values don't change as they do in the example code. I imagine this is because the GPIO clock isn't enabled?

So I changed the initialisation to be done with emlib and Board Support Package functions as it is in the examples (again, not sure what Im doing so might have done something wrong). The initialisation seems to work now and I have a task should turn some LEDs on but after calling vTaskStartScheduler();, the code now gets stuck at svc 0 in

vPortStartFirstTask
/* Use the NVIC offset register to locate the stack. */
ldr r0, =0xE000ED08
ldr r0, [r0]
ldr r0, [r0]
/* Set the msp back to the start of the stack. */
msr msp, r0
/* Call SVC to start the first task. */
cpsie i
svc 0

Are you saying the LEDs are working now? (before the scheduler is started, so just toggling LEDs from main())

What happens when svc 0 is called? Where does it go? It might be just that the FreeRTOS SVC handler has not been installed. If that is the issue take a look at FAQ number 1 here, there is a special note for Cortex-M users which you will see in red: http://www.freertos.org/FAQHelp.html

From your support requests it sounds like something has changed significantly since the EFM demo was created. I suspect the libraries used by the tools are different - that would make sense from the symptoms you describe.

Regards.

Ok included those 3 #define statements (but didn't end up commenting anything out) and I can now run multiple tasks that change LEDs etc.

I have one last question (and sorry if this is out of the scope of this thread):
I want to now reproduce the examples in the "Using the FreeRTOS real time kernel" book. I've included the basic_io.c file in my project but when I compile I get the following errors:

Warning[Pe223]: function "fflush" declared implicitly
Error[Pe020]: identifier "stdout" is undefined

It seems that this is being caused by _DLIB_FILE_DESCRIPTOR preventing these elements being declared in stdio.h, but I can't seem to change it's value without preventing the project from compiling. How can I change this flag? Or am I going about this the complete wrong way?

That file has to be tailored to the platform on which you are running the demos. Basically you just need to provide a mechanism to print strings to somewhere visible. Some systems can use semihosting to just call printf() and have the strings appear in the console window of the debugger - in which case your environment has to be set to know what stdout is [generally using semi hosting in a real project is a bad idea as it interferes with timing]. Other systems just write the string to a UART or CDC port, in which case you can replace the printf() with a UART write function (or whatever is needed) and the dependency on stdout should disappear.

Regards.