FreeRTOS 2022.12.01 On NIOS II - demo example failing some tasks

Kernel
1

It took a bit of work, but I have FreeRTOS running on a NIOS II on an Altera Cyclone V.
The basic “Hello World” with two tasks seems ok, but when I run the Demo from the NIOS II folder, I get failed tasks off and on. If I cut back the number of tasks it seems to clear up.
What is the best way to work out what the issue(s) are? The task prvCheckTask reports pass/fail, but no indication as to what the issue of the given task might be.
I think I have the stack checking stuff enabled… Any tips to getting the demo working would be good.
I’m using a CVGT board from Terasic, with 1 Gigabye dram. Is that enough to run the full demo?

2

Hi @gordwait
Welcome to FreeRTOS Community Forums!

Few things to check out which task might be failing to cause the prvCheckTask to fail in the demo.

  1. Do you have configASSERT enabled in FreeRTOSConfig.h ? If not, you can define configASSERT in a similar way
#define configASSERT( x ) if( ( x ) == 0 ) { taskDISABLE_INTERRUPTS(); for( ;; ); }
  1. Since you mention , if the number of tasks are reduced the CheckTask seems to be passing,
    it can be better to have a Malloc check, to see if the amount of heap supplied to the application is enough.
    For this define macro configUSE_MALLOC_FAILED_HOOK as 1 in FreeRTOSConfig.h
    and have a hook function defined similar to Stack Overflow in the main file of the application
    An example :
void vApplicationMallocFailedHook( void )
{
	/* If configUSE_MALLOC_FAILED_HOOK is set to 1 then this function will
	be called automatically if a call to pvPortMalloc() fails.  pvPortMalloc()
	is called automatically when a task, queue or semaphore is created. */
	for( ;; );
}

  1. Check the value of configTOTAL_HEAP_SIZE in FreeRTOSConfig.h , if it is less enough for all the tasks to run simultaneously in the demo.

  2. Finally, enable debugger and put a breakpoint in prvCheckTask and we can iterate over all the checks to see if any specific tasks are failing, in case memory allocation is not the issue.

3

Great! I will try out your suggestions and see what I learn.
I already have at least some improvement, I read about the MemMang options and switched from heap_1.c to heap_4.c .

4

One question - how much memory is required to run all the tasks in the demo?

5

So it seems the heap_4.c fix was the ticket. Probably the demo ran out of memory when heap_1.c was in place, as it can allocate but never free any memory. Used up all the memory shortly.

6

It seems that the COM test needs a serial port with a hardwired loopback? My test setup does not include the serial port hardware, so it fails, but I’m not concerned about that one…
All other tasks can run simultaneously. On to enabling my ethernet port!

7

Great! Thanks for reporting back.

8

Not quite out of the woods yet unfortunately. The demo test code will run for several hours but eventually the Block test will start to fail, overnight for example.
Oddly, the blink leds keep going, so none of the traps I set (for malloc etc) have been triggered.
Any suggestions?

9

If only BlockTest fails after some time, one way could be to comment out the other tests in prvCheckTask , keep a breakpoint in printf

        if( pcMessage != NULL )
        {
            printf( pcMessage );
        }

once the BlockTest starts failing , this breakpoint should be hit . Then we can keep a second breakpoint at xAreBlockTimeTestTasksStillRunning function in Demo\Common\Minimal\blocktim.c , to see due to which reason the test fails.

The blink LEDS keep going as per this code , but their frequency would be reduced.

        /* Provide visual feedback of the system status.  If the LED is toggled
        every 5 seconds then no errors have been found.  If the LED is toggled
        every 500ms then at least one error has been found. */
        vParTestToggleLED( mainCHECK_LED );
10

Excellent idea, I’ll try that out.