S32K144 EEPROM setup causes reset in release version

[davithakobyan]

Dear All,

On S32K144EBV board I integrated the flash partitioning example into our project to setup EEPROM which works fine in Debug mode (with debugger as well as standalone).

However, in release mode the board continuously resets when reaching the following line (for convenience the call history is also presented):

if (0u == flash_ssd_config.EEESize)
{

      FLASH_DRV_DEFlashPartition(&flash_ssd_config, 0x02u, 0x08u, 0x0u, false, true) {

            {

                  ...

                  /* Calling flash command sequence function to execute the command */
                  ret = FLASH_DRV_CommandSequence(pSSDConfig) {

                        ...

                        /* Clear CCIF to launch command */
                        FTFx_FSTAT |= FTFx_FSTAT_CCIF_MASK;    // <- MCU resets at this line                                                                                                     // FLASH_DRV_CommandSequence executes from RAM

                  }
            }
      }

}

Could someone suggest what might be wrong in the release version?

Thanks a lot for any help.

[davithakobyan]

To see the problem I have prepared a small example project.

The debug version seems to run properly, however the release resets after reaching the above mentioned EEPROM partition function.

Probably there is some simple points which I miss but noticed the following strange thing:

1. The S32K144.h file generated by S32K Design Studio has no such defines as MSCM_OCMDR_OCM0_... or MSCM_OCMDR_OCM2_... which are needed by the partition function. What is the reason behind this? The older version seems to have the these defines.

2. In the initial part of bl_init_internal_eeprom function after each line like:

      MSCM->OCMDR[0u] |= MSCM_OCMDR_OCM0(0xFu) | MSCM_OCMDR_OCM1(0xFu) | MSCM_OCMDR_OCM2(0xFu);

   i put a dummy delay as without a delay even in debug mode the board reaches some undefined behavior.

I use Segger J-flash Lite to program either debug or release S19 files generated during the build. When using debugger (of course for the debug executable) the example seems to be working.

Thanks for any help.

[danielmartynek]

Hi Davit,

just regarding the MSCM->OCMDR[0u] register,

the OCM0 and OCM2 bit-fields are reserved on the production version 0N57U of S32K144.

There is only OCM1.

Please see Section 34.4.2.18.3, RM rev.7.

Regards,

Daniel

[davithakobyan]

Thanks Daniel for point it out.

I tried to leave only MSCM_OCMDR_OCM1_... in each of those line in the project code (function bl_init_internal_eeprom) but the results is still the same: release build causes reset when programming after chip erase (i.e. when EEPROM is to be first created).

Thanks a lot for any resolution.

[davithakobyan]

Some more information.

The same reset problem happens in the original flash partition example in release version if one sets the optimization level to O3 and undefine DEV_ERROR_DETECT macro from the settings.

Since DEV_ERROR_DETECT should not influence anything in the program one may assume that the stack gets corrupted somewhere with at least at optimization level O3. So other optimization levels like Os or O2, presumably, runs just by chance since a small customization of the original flash partition project makes also the release version fail with optimization level Os (have not tested much with O2).

Could someone from NXP comment on this?

Thanks in advance.

[danielmartynek]

Hi,

Please refer to SDK release notes that can be found in the S32DS installation folder.

There is only -O1 option.

The below screenshot is from S32SDK_S32K14x_BETA_1.9.0 ReleaseNotes.

Regards,

Daniel

[Catosh]

Hi Daniel, 

I have a similar issue trying to partition the memory using -O3 option.

Is it correct to say that all the sdk has been qualified with -O1 and more aggressive optimizations are not reliable with this version of the SDK?

Thanks and kind regards, 

L.

[danielmartynek]

Hi,

This is the level used during testing/validation of the drivers.

The functionality can't be guaranteed at other levels.

BR, Daniel   

[tommy1231]

Hi Daniel,

I ran into this issue as well and have a couple additional questions

1. Since the SDK only supports level 1 is there a way to change the default projects to match this?

2. Is there an easy way to set the SDK to level 1 but optimize other code to 3?

2. For our bootloader we are using the "Optimize for size (-Os)".  Are we safe to use that or can we only use the "-O1"

Thank you,

Tom

[davithakobyan]

OK, some more information:

Interestingly, when DEV_ERROR_DETECT is not defined in the project settings with release version at optimization level O3 compiler seems to decide to make FLASH_DRV_CommandSequence function inline and places it into each reference function body which is bad as FLASH_DRV_CommandSequence is assumed to be in RAM.

One solution is to declare FLASH_DRV_CommandSequence as follows:

#define START_FUNCTION_DECLARATION_RAMSECTION_NOINLINE
#define END_FUNCTION_DECLARATION_RAMSECTION_NOINLINE        __attribute__((noinline, section (".code_ram")));

START_FUNCTION_DECLARATION_RAMSECTION_NOINLINE
static status_t FLASH_DRV_CommandSequence(const flash_ssd_config_t * pSSDConfig)
END_FUNCTION_DECLARATION_RAMSECTION_NOINLINE

With this modification the release version with O3 optimization works.

[davithakobyan]

Some more information.

Flashing  the debug version (with Segger J-Flash lite) seems to also cause the same problem. But when investigating the code with debugger the above line does not cause reset and passes normally.

The linker script is organized correctly. I have checked in Reset_Handler that PC and MSP registers have the correct 0x410 and 0x20007000 values.

So far I did ~30 Chip erases. Could this be the reason of such behavior?

What can be the reason of reset when board is flashed not using debugger?

Thanks.

[chenze]

Hello, I have the same problem, How did you finally solve the problem