FLASH_LDD FTFE_PDD_DisableInterrupts issue

[davidschroeder]

I'm having an issue with FLASH_LDD driver on a MK20FX512. When completing an erase followed by a write operation (through IntFLASH's SetFlash method) the Command Compete interrupt handler attempts to disable the command complete interrupt by calling FTFE_PDD_DisableInterrupts.

if (DeviceDataPrv->DataCounter == 0U) { /* If all the data has been successfully proceeded, finish the operation */
      DeviceDataPrv->CurrentOperationStatus = LDD_FLASH_IDLE; /* If yes, change the operation state to IDLE */
      FMC_PDD_InvalidateFlashCache(FMC_BASE_PTR);
      PE_NOP();
      PE_NOP();
      PE_NOP();
      FTFE_PDD_DisableInterrupts(FTFE_BASE_PTR, FTFE_PDD_COMMAND_COMPLETE_INT); /* Disable the Command complete interrupt */
      IntFlashLdd2_OnOperationComplete(DeviceDataPrv->UserDataPtr); /* Invoke the OnOperationComplete event */
      return;                          /* End */
    }

However it appears that most of the time it doesn't work, but every once in a while the operation completes successfully. When it doesn't work the application gets stuck with the interrupt handler being continuously called.

Stepping with the debugger and watching the FTFE_FCNFG register, if I break on line 8 above, I can see that the interrupt enable flags are still set. If I break on line 7, and step through the assembly code it works correctly and I don't encounter the problem.

As this suggests a timing issue, or a race condition, I modified the code to disable interrupts ( asm("cpsid.n i");)before calling FTFE_PDD_DisableInterrupts. This seams to resolve the issue, however I'm not sure if this is a real fix or if I'm just shifting timing enough to avoid the issue.

**     Processor   : MK20FX512VLQ12

**     Component   : FLASH_LDD

**     Version     : Component 01.099, Driver 01.12, CPU db: 3.00.000

Thanks,

   ~Dave

[vfilip]

Hello,

could you please post here some simple demonstration project in order to analyze it on our side?

Best regards

Vojtech Filip

Processor Expert Support Team

[davidschroeder]

Vojtech,

    Attached is a simplified project that exhibits the symptoms describe. Of interest, I had to a the USB_CDC_Class and USB_DEVICE_STACK before the problem showed up. Without the USB components the write worked correctly.

Thanks,

    ~Dave

[vfilip · Accepted solution]

Hello,

please try to add one or more PE_NOP(); It’s because on some Kinetis MCUs we have identified strange behavior in some cases after calling the FMC_PDD_InvalidateFlashCache and adding additional NOP after invalidate flash cache. That might be the cause of issues also in here.

We have also identified a problem in FTFE_PDD_DisableInterrupts macro that might be involved in the problem cause.

Please find attached fixed PDD module. Please copy it over existing file. It is located under the following path: {CW}\MCU\ProcessorExpert\lib\Kinetis\pdd\inc\

Best regards

Vojtech Filip

Processor Expert Support Team

[bflorac]

I know this is old and was marked "solved" but has anyone really determined the cause? I have been working on some older code. It has the same problem. The code generated by PE puts in 3 NOPs. However, I found that I needed increase this to 6 to make it work. Logically, if we are really clearing the cache, one might think we need to have 8 NOPs for the 8-way cache. And, according to the documentation, writing to the flash control register should be done from RAM, not while running from flash! Which, is logical as the NOP are just part of the same code you are trying to avoid using until the cache is really flushed. I expect that the cache only needs to be cleared if the bank being programed is the same bank that you are executing from so in many cases, it is not needed.

[davidschroeder]

Vojtech,

      Adding an additional PE_NOP does not correct the problem (I'd actually tried that before disabling interrupts). I installed the new FTFE_PDD.h you sent, it also does not seam to have any effect on the problem.

~Dave

[Petr_H]

That's strange... Please try to comment the line FMC_PDD_InvalidateFlashCache(FMC_BASE_PTR); , check if it helps and let us know the result.

This way we'll know if the problem is related to caching.

Best regards

Petr Hradsky

Processor Expert Support Team

[davidschroeder]

Peter,

   Yes, If I comment that line out it does not get stuck.

~Dave

[Petr_H]

Ok, I'll pass it to the development team for analysis of the cause of the problem. For now, please use this as a workaround. You can disable regeneration of the component code using the component pop-up menu command "Code generation -> Don't write Generated Component Modules".

There is only a potential risk that if your application would read the written data immediately after writing them it could read old values. If you'll encounter such issues, please let us know.

Best regards

Petr Hradsky

Processor Expert Support Team