In KDS 3.2.0 volatile pragma is inactive with pointer In Release Mode

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

In KDS 3.2.0 volatile pragma is inactive with pointer In Release Mode

815 Views
didierjeanjean
Contributor III

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.

Thanks

Didier JEANJEAN

Labels (1)
0 Kudos
Reply
4 Replies

645 Views
didierjeanjean
Contributor III

Hello,

I found the solution in fact the qualifier "volatile" must be positionned just before the pointer
to qualify the pointer, like this:

uint8_t * volatile Pointer

If it is positionned first it qualify the uint8_t value and not the pointer

I make the modification and all become OK.

Best regards

0 Kudos
Reply

645 Views
Alice_Yang
NXP TechSupport
NXP TechSupport

Hello Didier,

You can change the Optimization level at here :

pastedImage_1.png

Change it to "None(-O0)" .

Hope it helps

Alice

0 Kudos
Reply

645 Views
didierjeanjean
Contributor III


Thank you very much Alice,

You give me information to find where i can found optimization parameters.

But i need local solution to keep optimization for the other part of the code.

And i find a solution using pointer of pointer value that i named "ptptwrite"?
and even more volatile pragma is un-necessary.

Using like this :

In declaration :
    uint8_t *ptwrite;
    uint8_t **ptptwrite= &ptwrite;// Solve simplification issue in Release mode to force read from RAM that is modified by interrupt

In interrupt code this give for reading port and incrementing ptwrite

    *(*ptptwrite)++ = (uint8_t)(BOARD_BUS_READ_BYTE_GPIO->PDIR);

In FreeRTOS task for reading ptwrite in RAM :

    while ((ptread <= ptend))
    {
        if (ptread != *ptptwrite) // using pointer of pointer to force read in RAM
        {
            ptread++;
        }
    }
    ptread = ptbegin;

Didier JEANJEAN

0 Kudos
Reply

645 Views
Alice_Yang
NXP TechSupport
NXP TechSupport

Hello Didier,

OK, thank for your sharing .

BR

Alice

0 Kudos
Reply