Compiling FreeRTOS for SH-2A under GCC/GNUSH

bryanpape wrote on Friday, August 16, 2013:


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:!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 “” (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.


davedoors wrote on Friday, August 16, 2013:

From your description is sounds like you are attempting two things at once. First to change the target hardware, second to change the compiler. Can you try re-targeting the project that uses the Renesas compiler from the 7216 to the 726B to make sure that part works before switching compilers?

I don’t know anything of the SH specifics, but if it uses a separate stack for interrupts then be aware that the stack overflow checking in FreeRTOS (assuming you have it switched on) does not check for overflows in the interrupt stack.

Can you see what it is about the RTE instruction that makes it crash? I guess it will be popping a return address and the address is invalid, which could be because the stack pointer is invalid or because the stack has been corrupted. If you could determine which it would be helpful to your debugging.

Another good test is to create two tasks that just fill all registers with known values (both tasks using different values) then sit in a loop checking that the values have not changed. Start without preemption so both tasks have to yield to each other. If that works without any registers being corrupted remove the yield from one of the tasks and turn preemption on, to see if that also runs without any corruption. If that scenario runs then the context switching is normally ok and the problem could lie somewhere else, like critical section management.

Hope something here helps.

bryanpape wrote on Friday, August 16, 2013:

Hi Dave,

I think it’s a good suggestion to try compiling for the 726B under the Renesas compiler and see what happens.  I’ll go ahead and try that.

With regard to the RTE instruction, it appears to be returning to 0x00000010 instead of a valid address.

The original SH7216 demo included the register test code in assembly.  I’ll see if I can convert that over and see what happens.

Also, it appears that FreeRTOS is supporting the Renesas RX line, both for the Renesas compilers as well as GNURX.  Are there any plans to provide GNUSH support officially for SuperH?


rtel wrote on Friday, August 16, 2013:

Are there any plans to provide GNUSH support officially for SuperH?

Nothing planned at the moment - sorry.