Yes. The prototype changed so the TaskIncrementTick() function returns a value indicating whether a context switch is required or not. https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/main/History.txt#L989
Hi all,
thanks for all the help.
I do some steps foreward, but the forum blocked me so I can’t post my report.
(Not more than 4 replys allowed for me? My replays that bad?)
That is not so nice …
Current standings:
I solved the xTaskIncrementTick and get the green light afterwards from Richard.
I found a bug in Intels ecosystem which sets INCLUDE_vTaskDelay to zero or whatever, but it was checked in the config editor. No problem is hard coded for now.
I have a FreeRTOS distribution which compiles and I have a simple app which compiles.
Unfortunately, it do nothing.
I comment eveything out (from FreeRTOS) so only LEDs where turned on and I take this code from a running sample, I am able to step this code line by line, but LEDs still dark …
Now I have to find out, what the altered code in the port, which maybe is called at startup do. As long as the LEDs staying dark, it makes no sense to start FreeRTOS scheduler.
If anybody have an idea, what to check and how, I will be very happy for an advice.
Otherwise it will be a long night here.
Ok, still blocked, hmmmm.
Found intresting. I started debugging from the very fist instruction. My main only has one line switching LEDs on. NO freeRTOS call, not one.
And during boot sequence the tasks.c file is loaded and queues were used and … why?
There is an if statement in the tasks.c file asking for ‘scheduler started’ and no, the scheduler is not started.
Ok, maybe the guy making the port and the sample do some very special, so I take a look into his (very complicated) code and … he starts the scheduler:
/* Finally start the scheduler. */
vTaskStartScheduler();
/* Will only reach here if there is insufficient heap available to start
the scheduler. */
for( ;; );
So business as usual. But why using semaphores, queues and tasks during boot?
And, the fact, that I can debug the code line by line tells me, hardware isn’t the problem, correct? And software (runtime) isn’t a big problem, correct?
No idea now and more than an hour to wait until unblocked …
With best regards
Gerhard
PS: Still blocked for another 59 minutes, thanks a lot …
Hi all,
wow, was able to post an reply!!!
And here ist the best of all.
FreeRTOS runs on NIOS 2 !!!
My LED is blinking, one task, one task delay, the classic test.
What was the reason? No idea. I started everything new (the machine too), also a classic procedure in such situations, and hui, helps.
The printf function fails for some reason, maybe I missed something.
Thanks all a lot for helping so far.
With best regards
Gerhard
PS: If my posts were not that bad in your oppinion, please don’t block me most of the day, thanks.
The forum has various auto antispam features - I bumped your trust level up manually so hope that won’t happen again.
THANKS Richard.
Ok, one more problem.
Here my task:
void vTaskCode( void * pvParameters )
{
uint8_t ledState = 0x00;
for( ;; )
{
// Task code goes here.
vTaskDelay(1000);
ledState = !ledState;
IOWR_ALTERA_AVALON_PIO_DATA(PIO_LED_BASE, ledState);
//printf("Heureka!!\n");
}
}
Without the printf everything is fine, with printf I get the message out, but only when I use the debug uart (jtag_uart_0), when I used the ‘uart’ as FreeRTOS needs I don’t get a message.
In both cases the system stopps working ==> LED stops blinking.
I want to use FreeRTOS to host an app with a command line interface (FreeRTOS CLI maybe) and therefore printf and its friends are essential.
Any idea where to start searching?
With best regards
Gerhard
That might be a dreaded stack overflow problem caused by usually stack hungry printf functions. You could try to increase the stack size of the task up to say 1000 or more.
On the other hand I’ve seen that configCHECK_FOR_STACK_OVERFLOW IS defined… is it possible that the program stopped in your provided vApplicationStackOverflowHook ?
Oh my god.
Yes. I keyed in 20 instead of 200, sorry to bother you with such a …
With best regads
Gerhard
Status update:
I have now three tasks running, two blinking LEDs and one is an echo pod for uart0. It works for some hours without failure, so the port isn’t that bad. ((If there is a stack corruption a 8MByte memory should wrap after that long time, I guess))
But more testing has to come.
Thanks all for helping.
I have to solve some small issues and after that I will send a zip with all the files so you can post a port & sample for NIOS 2 Gen 2 usable out of the box with Intel’s toolchain V20.1 which is the newest you can get for free. The currerent sample FreeRTOS.org provide is about 10 years old and the tool chain is looong outdated.
With best regards
Gerhard
[this text is just because I can’t post without at least 20 characters]
Hi Richard,
after fiddling aroud with this autogeneration stuff I get it running. Now you can create a new project for NIOS 2 Gen2 with the provides Eclipse version, and you have a sample project in the list of the samples provided by Intel, which uses FreeRTOS. It is a three task and one semaphore thing, demonstrating the basics for every (HW related) app.
Unfortunately, this app crashes after some inputs from the terminal (serial echo).
After a long night I maybe ‘found’ something.
When I rename the FreeRTOS subfolder which is created during autogeneration and copy the FreeRTOS subfolder from my ‘hand made’ first app to this place … works great.
I now have two versions of FreeRTOS files which may contain a significant difference.
Now I want to ask, if you will be so nice and check out, whats going on here? If so, I can post/send this two folders.
Unfortunately, the forum software don’t let me send attachments others than images.
What do I do?
Good project blinking LEDs and echos hundreds of characters by just holding down a key when the terminal program (TeraTerm) has the focus.
Bad project blinking LEDs and echos 10 to max. 100 characters, than stopps working, e.g. LEDs stop flashing too.
Thanks a lot for helping.
With best regards
Gerhard
If you can zip them up as small as you can, but still containing the necessary to build (so remove object files, etc.) you can then send them to me at r dot barry at freertos dot org.
Hi Richard,
seems to be another reason.
I found, that some times the app works and some times not. Do a lot of reading and playing around with parameters.
It helps to move everything hardware to lower interrupt priorities. I originally planning the interrupt chain, but maybe wrong. The jtag-uart-0, which is a special uart for debugging purposes has a lower interrupt priority than the standard uart I used. And using the jtag-uart-0 was less error prone.
And I disabled the SPI driver. The sample I started from was made for my CYC-1000 Arduino style board and they put an g-sensor on the board and using SPI for communication.
I don’t need that stuff, but I kept the SPI interface for later. Maybe the unused driver did strange things.
And I slow down the sys_tick from 1kHz to 100Hz, but the difference wasn’t significant.
After all that I was able to echo a ‘k’ for 30 minutes holding a key down (ok, not personally …)
I will start working on my app tonight, will see whats happen next. There will be some power cycles and programming cycles, good test conditions.
Thanks for helping so far.
With best regards
Gerhard
Hi all,
still unclear situation. After a power cycle problems were back but after programming the same version three times it start working. I do some changes to the source, compiles and after loading, works again.
So in the moment it looks fine, no idea whats going on.
Any idea where to look, what do test?
With best regards
Gerhard
Could there be something wrong with the power on sequence? Either the chip not being reset correctly (especially if there is a difference between running on the debugger and running without the debugger) or the C startup code leaving something uninitialised?
Hi Richard,
maybe. I started with a sample from Intel, here the reset input of the softcore is tied to Vcc.
Thats not too professional …
I changed this yesterday (quick and dirty) and connected the reset input to the ‘user-button’ of my PCB, but without debouncing, also not so nice.
I will try some delayed reset next. The clock generator (PLL clock multiplier) generates a ‘locked’ signal. I will use the signal to start a down counter and when this counter reaches 0 I will release the reset for the processor.
But: The two tasks blinking LEDs and the semaphore which protect the PIO works for hours, problems starting, when I try to use the serial interface …
So I don’t really believe that it is a hardware problem, but hardware should be a clean design, so I have to do it anyway.
But first I will finish the implementation of my little command-line-editor. I have it used in other projects, so I only have to plant in here …
With best regards
Gerhard
Hi Richard,
I also have the idea, that it may be a thermical problem. As I started yesterday morning, the board was ‘cod’ and I have problems to program the software into the FPGA/SDRam. After some tries the system works the whold day without error.
I tried this today, but first wait an hour, so the board gets warm, but … errors.
Intel bought this chips and tools from Altera and Altera used something called HAL, which is a collection of device drivers and support software.
There is one setting when I changed this, the systems don’t came up.
I will try a sample using an endless loop and only the device drivers for the serial board and checking out, what happens when I do the same setting changes. So we can sort out, if its a HAL a FreeRTOS or an FreeRTOS upon HAL problem.
With best regards
Gerhard
Hi Richard,
I learnd now to get more infos out when the system hangs.
It seems to be a ‘Bad Address’ trap. This only happens during accessing the serial line. Without accessing the serial line (e.g. no input via kbd or output) the system works fine.
The issue isn’t a thermal one, I can’t proof this theory. I found a file (.xml) containing some numbers and called ‘language.settings’ which is different between the app which always runs and my app. As soon as I override the file in my app with the other version my app starts working, but after some development cycles my app fails again.
And it is always the same behaviour, inpot + echo over serial line ==> crash.
I added a screen shot from the debugger, hanging.
With best regards
Gerhard
… and this function is called from port_asm.S ==> and thats FreeRTOS (port).
I try to add this file which I get from the port of FreeRTOS to Nios2. Maybe you can find something out …
port_asm.S.c (7.9 KB)
Ok, .S files are forbidden, so I renamed it to .c, sorry for that hack.
