Hello From France,
I use KDS3.2.0 with SDK 2.0 and FreeRTOS on MK22FN512VLH12 Kinetis microcontroler with OpenSDA Probe on FDRMK22F board.
I discover that in Kinetis Design Studio the volatile pragma is inactive in release mode.
Following is the condition that allow me to discover this problem.
I create a global array of 45KByte and use global pointer to adress this array like FIFO, with write en read pointer.
To optimize CPU cycle, for this array, i don't want to use mutex or semaphore wich are cycle consuming.
I increment a "Write" pointer in an interrupt with the highest priority = 0 and i read this pointer in a FreeRTOS task in lower priority. It is not necessary to use Mutex for this pointer because this pointer is only modifying by the interrupt and it is a 32bit pointer and reading 32 bit data is mandatory atomic on 32 processor and this resolve naturally the
possible conflict between interrupt and FreeRTOS low priority task that only read the pointer.
This system works very good in Debug mode but in Release mode, the interrupt incrementation is seeing in the debuger interface but is not see by the code.
To be more simple the "Write" pointer is incremented from 10 to 11 in the interrupt and i see the same in the debug interface "10" and "11" after increment but in the FreeRTOS task a simple comparaison with a value of "10" give a TRUE result. If i put a PRINTF"bidon/n/r"; just before the test the test read the good value of "11", if you see the assembler code you will see that the PRINTF force the compiler to take in RAM the true value of the pointer instead of keep a copie of the pointer in register that keep the initialisation value that is made just before.
Before that i use volatile pragma in the declaration of the pointer and it not solve the problem.
This prove that volatile pragma is inactive in KDS tools.
Is somebody found a workaround for that ? can it be possible to remove locally optimisation code that is more efficient that volatile for a variable.
In all case this seem a big problem, Can somebody of NXP can solve this compiler issue.
I can give the code that is very simple to help verify the issue.