I have just sent out the following message to the mailing list:
FreeRTOS.org V4.6.0 has just be released. This release changes the syntax
required to cause a context switch from within an ISR for ARM7/9 GCC ports
only, and corrects a mistake in a function prototype within queue.h that
could adversely effect 8 and 16bit users.
The following information is relevant to ARM7/9 GCC/Rowley users only.
With reference to the change to the syntax required to cause a context
switch from within an ISR: The change is unfortunately not backward
compatible with the old method, but as the new method does not place any
reliance on the compiler generated code, it should mean no further changes
will be required in the future, so worth the inconvenience.
In brief, the macros portENTER_SWITCHING_ISR() and portEXIT_SWITCHING_ISR()
are no longer supported (again, ARM7/9 GCC ports only). See the "RTOS
Configuration and Usage Details" section of the documentation page relevant
to your port for full instructions on how they should be removed/replaced.
All the ARM7 GCC demo applications have also been updated to demonstrate the
new method.
It is recommended that ARM7/9 GCC users upgrade to V4.6.0 to ensure correct
operation no matter what the compiler version, command line options, or
optimisation level.
Although I have not tested this change, I am quite certain that users will still need the -fomit-frame-pointer setting for unoptimized compiles using ARM GCC. This fix may address the ISR issue, but it has not addressed the problem with portSAVE_CONTEXT() (or should I say the GCC return from function problem) in which the context is stored on top of valid stack data.
Yes I agree with you. As per your previous email I’m hoping that the last two versions of GCC have not contained this but. Just in case I have left the -fomit-frame-pointer included in the compiler options to ensure correct operation with all versions (with the issues you have raised regarding debugging).
I looked at the changes required for a port such as the Atmel SAM7X GCC. Is it necessary to have the extra call to the handler? Can the code in the handler still be within the wrapper function much like the portENTER/EXIT_SWITCHING_ISR? Jumping to another function adds some overhead to the ISR. Maybe I don’t completely understand the end result of doing this. Would someone help me understand?
Thanks,
Darrik
P.S. What types of problems were people seeing that this is supposed to resolve?