am trying to work with flash memory on MPC5748G - a microcontroller from NXP running FreeRTOS 10.0.1, and I get some behaviour that I can't understand.
I am allocating memory manually, and the assignment seems not to work. However, I can reach the value at the address when using 'printf' - but only from the same function. (I'm using the copy of a pointer, to make sure that some sore of compiler optimization doesn't take place)
What is going on here?
void vFlashTask(void* pvParameters){
vTaskDelay(1000);
FLASH_DRV_Init();
uint32_t* val_ptr;
uint32_t* val_ptr_cpy;
val_ptr = (uint32_t *)0xFB8000;
val_ptr_cpy = val_ptr;
*val_ptr = 444;
DBGPRINTF("Task| value at xFB8000:%d", *val_ptr_cpy);
getValTest();
vTaskDelay(1500);
vTaskDelete(NULL);
}
void getValTest(){
uint32_t* val_ptr;
val_ptr =(uint32_t *)0xfb8000;
DBGPRINTF("getValTest| value at xFB8000:%d", *val_ptr);
}
Gives back (in UART Terminal):
[../include/flash.c:26]: Task| value at xFB8000:444
[../include/flash.c:37]: getValTest| value at xFB8000:-1
I am attaching also the screenshot from the debugger, which clearly shows that however memory at the xFB8000 is uninitialized (it has the value of 0xffffffff), but still, the printf function manages to print the correct value(??).
thanks in advance for any help!
My DBGPRINTF macro:
#define DBGPRINTF(f, ...) dbgPrintf("[%s:%d]: " f "\n", __FILE__, __LINE__, __VA_ARGS__)
void dbgPrintf(const char *format, ...){
va_list args;
va_start(args, format);
int len = vsnprintf((char*) uart_buffer, UART_BUFFER_SIZE - 1, format, args);
UART_SendDataBlocking(&uart_pal1_instance, (const char *)uart_buffer, len, UART_TIMEOUT);
va_end(args);
}
my compiler flags:
\S32DS_Power_v2.1\eclipse\../S32DS/software/S32_SDK_S32PA_RTM_3.0.3/rtos/FreeRTOS_PA/Source/portable/GCC/PowerPC" -I"C:\NXP\S32DS_Power_v2.1\eclipse\../S32DS/software/S32_SDK_S32PA_RTM_3.0.3/middleware/tcpip/tcpip_stack/ports/OS" -I"C:\NXP\S32DS_Power_v2.1\eclipse\../S32DS/software/S32_SDK_S32PA_RTM_3.0.3/middleware/tcpip/tcpip_stack/ports/platform/generic/gcc/setting" -I"C:\NXP\S32DS_Power_v2.1\eclipse\../S32DS/software/S32_SDK_S32PA_RTM_3.0.3/middleware/tcpip/wolfssl/wolfssl" -I"C:\NXP\S32DS_Power_v2.1\eclipse\../S32DS/software/S32_SDK_S32PA_RTM_3.0.3/middleware/tcpip/wolfssl" -I"C:\NXP\S32DS_Power_v2.1\eclipse\../S32DS/software/S32_SDK_S32PA_RTM_3.0.3/rtos/FreeRTOS_PA/Source" -I"C:\NXP\S32DS_Power_v2.1\eclipse\../S32DS/software/S32_SDK_S32PA_RTM_3.0.3/platform/pal/inc" -I"C:\NXP\S32DS_Power_v2.1\eclipse\../S32DS/software/S32_SDK_S32PA_RTM_3.0.3/platform/drivers/src/flash_c55" -O1 -g3 -Wall -c -fmessage-length=0 -msdata=eabi -mlra -funsigned-bitfields -ffunction-sections -fdata-sections -fno-common -Wno-address -mcpu=e200z4 -specs=nosys.specs -mbig -mvle -mregnames -mhard-float --sysroot="C:\NXP\S32DS_Power_v2.1\eclipse\../S32DS/build_tools/powerpc-eabivle-4_9/powerpc-eabivle/newlib"
Solved! Go to Solution.
You can't write the flash in this way. It's necessary to use program and erase functions.
'-1' is correct result. Signed decimal 32bit number -1 is 0xFFFFFFFF in hex.
And the flash can be read anytime, no configuration is needed.
Regards,
Lukas
Hi,
this is caused by optimizations. I can see that you use level 1 (-O1 in compiler flags). If you set level 0, this issue will disappear. But this is not solution, of course. The solution is to use 'volatile' pointer to tell the compiler to avoid such optimization.
Regards,
Lukas
thanks for your suggestions.
Unfortunately, it didn't work.
If I use volatile pointers or change the optimization I can't assign a value to an address. The console gives back "
value at xFB8000:-1
both directly after the assignment, as well when called from a different function.
Is the memory correctly initialized? (the FLASH_DRV_Init() returns 0, but maybe there is more I should do to use flash?)
You can't write the flash in this way. It's necessary to use program and erase functions.
'-1' is correct result. Signed decimal 32bit number -1 is 0xFFFFFFFF in hex.
And the flash can be read anytime, no configuration is needed.
Regards,
Lukas
Thanks for your suggestions. You were right - the problem was writing to FLASH memory. It hasn't been correctly way initialized. The proper way to write to flash on MPC5748g using the SDK 3.0.3 is following:
- save flash controller cache
- initialise flash check and protect UT block
- unblock an address space
- erase a block in this space
- check if the space block is blank
- program the block verify if the block is programmed correctly
- check sum of the programmed data
- restore flash controller cache
The strange behaviour of printf and pointer was due to compiler optimization. After changing the compiler flags to -O0 (no optimization), the error was consistent.