STR9 - Timer interrupt problem

Kernel
1

gorlash3 wrote on Thursday, November 14, 2013:

<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
Okay, I'm using Stefano's STR9 package, which uses the ST libraries. 
The only changes that I made to his package, was to replace his hardware-initialization code with our hw init code, which is working on the board that I want to use FreeRTOS on.  I compile now with no warnings, and main() is running successfully.
I can access the LEDs on our board, and am using them to debug code execution.

However, I'm having problems getting the Timer to work, and of course without that, the RTOS isn't going to run!!

Looking first at Stephano's main timer (TIM2):

Try 1: I found that when using his timer-init function, the TIM2 ISR never got called at all!! 

Try 2: Since I had a working timer-init function in our existing code, I copied that init function over and modified it to set up TIM2.  In this case, the TIM2 ISR gets called exactly ONCE, but even the command to clear the interrupt flag is getting executed, the TIM2 ISR never gets called subsequently.

Try 3: I then copied over my TIM0 setup function and ISR, and I saw exactly the same thing as TIM2 - my TIM0 ISR gets called ONCE, and never gets called again.  This exact code is running fine in our non-RTOS firmware.

What could be interfering with the running of the timers??

Dan Miller




This email is free from viruses and malware because avast! Antivirus protection is active.


2

rtel wrote on Thursday, November 14, 2013:

Are you saying the timer does not run as expected in main() before you have made any FreeRTOS API calls? If so I’m not sure anything can be interfering. If you have made FreeRTOS API calls then, depending on the call, you may find interrupts have been disabled. That is done to ensure no interrupts attempt to use the kernel before the kernel has been started. Interrupts are automatically re-enabled when the kernel starts.

Some start up routines (the code that executes before main() is called) will perform some hardware initialisation, so it is possible you will get different behaviour when switching between different hardware setup routines. You may even find that Stefano’s original project contains a debugger script that has the debugger perform some hardware initialisation too.

Regards.

3

gorlash3 wrote on Thursday, November 14, 2013:

BTW, just as a sanity check (since I’m new to FreeRTOS, and RTOS in general), I am assuming that I need the timer running in order for task switching to work; is this correct?? Or are they independent?

Oddly enough, I’ve noticed that the web page is displaying, which implies that the Ethernet task at least is running, even though the timer doesn’t seem to be running.

4

edwards3 wrote on Thursday, November 14, 2013:

On the ARM9 yield uses SWI instructions and ticks user timer interrupts, so the two are independent of each other.

5

gorlash3 wrote on Thursday, November 14, 2013:

Okay, (I think) I understand what is going on… although I am starting the LED-flashing task ( vStartLEDFlashTasks() ), and therefore presumably it is running, that task calls vTaskDelayUntil(), which presumably won’t return if the timer tick is not running…

Well, hopefully Stefano will come up with something; he already replied to my email last night, but said he’d have to look at the old code, which he hasn’t looked at in a few years!!

6

gorlash3 wrote on Thursday, November 14, 2013:

Actually, there’s more going on than just the timer… I put a turn_on_LED(LED_GRN) call at the start of the LED task, and it never gets executed. So apparently, even though
xTaskCreate( vLEDFlashTask, …) is getting called, the task is never getting executed…

BTW, I went back and checked the return values for xTaskCreate(), and it is returning pdPASS for both LED tasks…