bryanpape wrote on Friday, August 16, 2013:
Hello,
I’m currently attempting to get FreeRTOS 7.5.2 working on the SH726B (SH2A-FPU core), using GNUSH to compile.
Unfortunately, after spending quite a while working on this, I haven’t had much success getting it to work correctly, so I thought I’d throw it out there to see if anyone might have some better luck.
A link to the project in its current form is here:
https://skydrive.live.com/redir?resid=FE66F2CBC7CF2F55!43917&authkey=!AEvashMSwuU49rA
The project is setup and buildable under the Renesas E2Studio environment. My specific target is the SH726B, and I’ve been using HEW to debug.
The official FreeRTOS SuperH port (from which this code is derived) targets the SH7216, and is intended to be compiled on the Renesas SH compiler.
I’ve made what I believe to be the appropriate changes necessary with regard to the interrupt vector table and iodefine files, modifying relevant aspects of the timer setups, as well as replacing hardware.h with intrinsics.h with those specific to the SH726B as needed.
The original SH7216 FreeRTOS port includes two key asm files: “portasm.src” and “ISR_Support.inc” (found in the “portable” directory). These contain the low level routines used by Free RTOS to switch between task register contexts. Due to the differences between the way the GNUSH assembler and the Renesas assembler behave with regard to how certain instructions are handled (e.g. 32 bit mov.l immediates), I chose to create a header and use the Renesas compiler to first convert it to a .rlib file. This solution appears to link ok in the new project, and the compiled code seems to be working as it should (I think), but I’m not an expert in SH assembly language, so this area might be worth looking at further.
In addition (to keep things simple), I’ve also removed all tasks except the LED trigger.
In building and debugging this project, it now appears that tasks are being created, and some task switching begins to take place, but the code crashes reliably after the fifth time vPortPreemptiveTick() executes . The point of failure seems to be the point at which it hits the RTE instruction, suggesting that the main MCU stack might be getting corrupted.
I’d appreciate any thoughts or ideas that anyone might have.
Thanks,
Bryan