I am am unable to get the Interval Timer to fire in the FreeRTOS Demo for the Starter Kit platform, RL78G13 (RL78 - R5F100LE). NOTE that *YRPBRL78G13 is defined (by default).
However the Timer fires in the IAR RL78 Async_Serial project (from the G13 tutorial projects)**!!??
*#1 - Using IAR Debugger (memory view*), have verified that the Interval Time vector (0x38) has been initialized and points to the ISR.
#2 - Have tried 3 variants of the Clock Generator setup (including the one from Async_Serial) and the** two choices from FreeRTOS v9.**0
#3 - Am using Interval Timer initialization code that Renesas Tech Support provided me (Applilet code)
#4 - In desperation have added the macro for enabling of interrupts in QueueSendTask (a* Breakpoint shows that this function is being called*!):
static void prvQueueSendTask( void *pvParameters )
... (code removed for brevity purposes);
/* Check the parameter was passed in correctly. */
configASSERT( pvParameters == mainQUEUE_SEND_PARAMETER )
APPRECIATE any pointers that you can provide!
However the Timer fires in the IAR RL78 Async_Serial project (from the
G13 tutorial projects)**!!??
//#1 - Using IAR Debugger (/memory view/), have verified that the
Interval Time vector (0x38) has been initialized and points to the ISR.
Does the IAR debugger provide a peripheral view that shows how the
timer's registers are configured? If the registers in the project that
works are configured the same as the registers in the project that
doesn't work (and you are 100% sure that is the case), then I would
assume it was something outside of the timer's set up that was causing
Interrupts will deliberately be left disabled between the first call to
a FreeRTOS API function and the first task starting to execute. As a
first step (to ensure the compiler syntax, project settings, start up
code, etc. are correct - as the required syntax can change between
compiler versions) I would recommend creating a dummy program that
configures and uses the timer BEFORE any FreeRTOS functions are called.
If that works, then we can move forward bit by bit until we find the
place where the timer stops working.
For example, you can add code like this to the start of main() - before
any other functions are called - where the function names are
descriptive of what the function should do:
int main( void )
// Sit here to make sure no other code runs.
In the above I'm suggesting configuring the timer into an auto reload
mode, so it counts to a known value (or down to 0 if its a down
counter), reloads itself, then counts again. Watch the value of the
timer in the debugger (or read it in the for(;;) loop if it can't be
viewed in the debugger).
Is the timer counting and reloading as expected?
If so, re-configure the timer so it not only counts, but generates an
interrupt each time it reloads. Put a break point in the interrupt handler.
Does the interrupt handler ever get hit? If not, do any interrupt
handlers get executed?
Thanks for your prompt response!!
Excellent suggestions, was temporarily pulled off the project but now getting back to it.
My first try was to hang in the for loop in start of main() - but didn't hit a breakpoint in the ISR (which is declared in assembly language). My next step will be to add the dummy function within the FreRTOS project as you suggested above.
I appreciate the advice given above. As you know I had to migrate some of the source for compatibility to more recent version of Assembler & Compiler (previously described).
The final change to make this Demo work was to notice that the IAR IDE menu contained an item named Simulator. After changing the Options -> Debugger from Simulator to E1 (for Renesas Emulator pod that connects to the Renesas Starter Kit) that menu item is replaced with the wordd Emulator, the Interval Timer interrupt worked. Helps to interact with the hardware instead of a Simulator!!