S32K116(EVAL) - EEE Write access / Partitioning under OpenSDA / P&E

[huffymchuf]

Hello NXP!

I am having difficulties when trying to debug with said debug configuration in conjunction with EEE-Write accesses and Flash partitioning.

* Tested with S32 Design studio (gcc) (Issues 1 + 2) and IAR workbench (IAR compiler) (Issue 2)

* Used S32K116 - Example project as basis for S32DS

* Used NXP flash drivers (Issues 1 + 2)

Issues:

1) Partitioning in SW

Target is empty / completly erased and You want to use NXP flash driver FLASH_DRV_DEFlashPartition in order to partition while debugging.

If You do not place a breakpoint within FLASH_DRV_DEFlashPartition(), it breaks debugging (don't know if program counter runs amok or something else happens, but You have to leave debug session and restart it).

2) Writing to EEE

If You do not step through every single copy-step (1/2/4 byte at a time), but try to step over FLASH_DRV_EEEWrite() instead, debug process does not work anymore and You have to start a new debug session.

If I perform each indiviual 4/2/1 - byte copy steps, EEE works (Retains new data after removing power and powering on again).

(Read accesses to EEE work just fine)

Debugging including write access to EEE is pratically impossible this way.

Has anyone else had the same experience?

Is it the OpenSDA/P&E drivers causing this?

Regards,

Sascha

[huffymchuf · Accepted solution]

After reading through the AN11983 once more and looking into Your example code (Example: S32K144 EEEPROM usage ), I realized that I overlooked this info.

In essence: You do have to wait after every write access.

Sorry for wasting Your time.

I got the wrong impression that You could create (big) write jobs and let the controller handle them in the background.

(I previously worked with a S12XE controller, and there You could simply change EEE-RAM contents as You liked, so I expected a similar behavior here).

[huffymchuf]

Update:

I made a big mistake :S

I initialized Callback part of Flash-Driver-structure NULL instead of NULL_CALLBACK. ( flashSSDConfig.CallBack = NULL instead of flashSSDConfig.CallBack = NULL_CALLBACK);

This should explain why my program ran into default-ISR when calling FLASH_DRV_DEFlashPartition() and FLASH_DRV_EEEWrite().

Still there is one main issue remaining.

I do not want to wait after each write-access to EEE for the write operation to complete, which is why I only used FLASH_DRV_EEEWrite() for testing purposes.

Meaning if You write something like this instead of using FLASH_DRV_EEEWrite():

// Size > 4, address starting at FlexRAM-Startaddress

for(uint32_t Idx_U32 = 0; Idx_U32 < size; Idx_U32+=4)
{
   *(volatile uint32_t *)address = sourceBuffer[Idx_U32];
   address+=4;

}

-> You get issues as described in this thread.

Only if You wait, this will succeed.

for(uint32_t Idx_U32 = 0; Idx_U32 < size; Idx_U32+=4)
{
   *(volatile uint32_t *)address = sourceBuffer[Idx_U32];
   address+=4;
   //Wait till EEERDY bit is set
   while (0U == (FTFx_FCNFG & FTFx_FCNFG_EEERDY_MASK))
   {
   }
}

Is this behavior intended?

Should You have to wait after each write access before starting the next?

I read through AN11983 and did not get this impression.