KEA-64 suspends during internal EEPROM erasing

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

KEA-64 suspends during internal EEPROM erasing

5,129 Views
mortyhsueh
Contributor II

Hello,

 

I am working on a KEA64 and used Processor Expert to generate drivers of internal EEPROM (IFsh1: IntFLASH).

EEPROM read/write works great, but main loop and other interrupts are suspended during EEPROM erasing.

 

Firstly, I suspect the while loop which is used for erasing complete detection in EraseFlash function stalls all process, then I use "SetWait" method to avoid the while loop.

byte IFsh1_EraseSector(IFsh1_TAddress Addr) {   LDD_TError                 Result;     if (IFsh1_CmdPending) {     return ERR_BUSY;   }   IFsh1_CurrentCommand = IFsh1_CMD_ERASE_SECTOR;   IFsh1_CmdPending = TRUE;   Result = IntFlashLdd1_Erase(IntFlashLdd1_DevDataPtr, (LDD_FLASH_TAddress)Addr, 1U);   if (Result == ERR_OK) {     if (IFsh1_WaitForCommandDone) {  /*SetWait(False)to disable the wait loop as below. */       do {       } while (IFsh1_CmdPending);       Result = IFsh1_CmdResult;     }   } else {     IFsh1_CmdPending = FALSE;          /* Command parameter error */     if (Result == ERR_PARAM_ADDRESS) {       Result = ERR_RANGE;     }   }   return (byte)Result; }   

However, main loop and interrupts still suspend.

 

I've checked the reference manual of KEA64, but nothing had been mentioned.

Is the situation caused by innate hardware limitation of KEA64 or ARM cortex-M0+?

Please give me some advice.

 

Thanks,

Morty

 

May 23, Update:

Attached source code of a simple example. 

Original Attachment has been moved to: EEPROM_Eval.zip

Labels (1)
Tags (2)
17 Replies

4,137 Views
gusarambula
NXP TechSupport
NXP TechSupport

Thank you for posting the solution to this issue. If MCM_PLACR [ESFC] = 0 and at the same time all interrupts and sub-functions are in RAM this issue disapeared.

Regards,
Gustavo

0 Kudos
Reply

4,334 Views
jeremyzhou
NXP Employee
NXP Employee

Hi Morty,

I was wondering if you can share some kinds of information about the application, production, it can help us to investigate the application further.
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
Reply

4,334 Views
jeremyzhou
NXP Employee
NXP Employee

Hi Morty,

I'll inform you ASAP when I receive some replies.

Thanks for your patient.

Have a great day,

Ping

4,334 Views
mortyhsueh
Contributor II

Hi Ping,

Watch dog triggered is not the root cause.

Do you have any ideas regarding this problem?

Thanks a lot.

0 Kudos
Reply

4,334 Views
jeremyzhou
NXP Employee
NXP Employee

Hi Morty,

The most updated reply from the R&D team.

I do the similar test in my side, and just one case can get the same issue as you share, that is enable "ESFC" bit in MCM_PLACR, if this bit is set, then MCU is stall when EEPROM do sector erase, after clear this bit, it can work well.

pastedImage_0.png

Yellow is to indicate the status of the EEPROM sector erasing , when it is low, EEPROM sector erase is on-going.

and Blue is to use one timer to toggle one GPIO in its ISR.

also please refer to attached code, and when input 'y' with UART1, it will trigger the EEPROM sector erase one time.

so conclusion is it allow EEPROM sector erase and flash read operation simultaneous,however, please note if enable "ESFC" bit,  MCU will be stall when flash is busy.


Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
Reply

4,334 Views
mortyhsueh
Contributor II

Hi Ping,

Sorry for late reply.

I've checked the "ESFC" bit in MCM_PLACR in my project, it always kept "0", and the problem still persists.

By the way, that example provided by R&D team seemed not to use KEA64. Instead, it used for KE series.

pastedImage_1.png

Please check again.

Thanks a lot.

Morty

0 Kudos
Reply

4,334 Views
jeremyzhou
NXP Employee
NXP Employee

Hi Morty,

It seems the priority to operate flash read and EEPROM erase regard to the question at the issue.

It needs the designers to confirm it, any update will share to you.
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
Reply

4,334 Views
jeremyzhou
NXP Employee
NXP Employee

Hi Morty,

I'll appreciate a lot if you can upload the same experiment demo, then after replicate the testing result, I can report the kind of phenomenon to R&D team for checking.
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

4,334 Views
mortyhsueh
Contributor II

Hi Ping,

Did you receive any reply from R&D team?

Please help us to track this problem.

Thank you!

Morty

0 Kudos
Reply

4,334 Views
jeremyzhou
NXP Employee
NXP Employee

Hi Morty,

R&D has found the root cause of the issue, the watchdog reset causes the issue.

Please try to add feed dog in function "scheduler" and "EEPROM_WriteTrigger". please refer to attached code.
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
Reply

4,334 Views
mortyhsueh
Contributor II

Hi Ping,

Could you please help me again to report the problem to R&D team?

Thanks a lot.

0 Kudos
Reply

4,334 Views
mortyhsueh
Contributor II

Hi Ping,

Thanks a lot!

But the original setting of watch dog period is 1000ms and watchdog is cleared in main loop everytime.

Although I think watchdog trigger is not the root cause of this problem, but I replace the Task_10ms.c and Scheduler.c provided form R&D team.

Please refer to the result as below, the problem is still present.

pastedImage_0.png

Please investigate it.

Thanks!

0 Kudos
Reply

4,334 Views
mortyhsueh
Contributor II

Hi Ping,

Thanks for your patience, I had attached the source code already.

And I can reproduce this problem with this example.

Please refer to the top of this discussion or download via this link:

https://community.freescale.com/servlet/JiveServlet/download/394552-1-379109/EEPROM_Eval.zip

0 Kudos
Reply

4,334 Views
jeremyzhou
NXP Employee
NXP Employee

Hi Morty,

After had a brief look through the statement, I'd highly recommend that you can use the Step into feature to find out the code line that set the PRIMASK register. When set, it blocks all interrupt apart from the nonmaskable interrupt and the hard fault exception.

Hope it helps.
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
Reply

4,334 Views
mortyhsueh
Contributor II

Hi Ping,

Thanks for your suggestion, I 've used Step info to check the PRIMASK register, but no bit set. Erase.png

Besides interrupt, all process suspends until erasing complete.

I realize that there is only one flash controller in KEA64. EEPROM are also controlled by the flash controller.

Is it possible that all process is halted by the controller during EEPROM sector erasing?

Regards,

Morty

0 Kudos
Reply

4,334 Views
jeremyzhou
NXP Employee
NXP Employee

Hi Morty,

In my opinion, other interrupt can arise during the Flash or EEPROM command sequence.

And I'd like to know what the kind of experiments you did, then you got the conclusion that all interrupt would be suspended during the erasing sequence.

I'll also replicate the kind of experiments with my board.
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
Reply

4,334 Views
mortyhsueh
Contributor II

Hi Ping,

Thanks a lot!

For reproducing this problem, I used TRK-KEA64 EVB and created a simple example which all components are created by Processor Expert. Besides, I also captured the waveform for your reference.

Configuration of the example on TRK-KEA64 EVB is listed as below.

EEPROM erasing is triggered by pushing "Button 0" on EVB.

  1. I/O LED 1 level high presents the EEPROM is erasing.
  2. I/O LED 2 toggling presents the 200us ISR is active.
  3. I/O LED 3 toggling presents the main loop is active.

pastedImage_4.png

According to the experiment, I suspected 200us periodic ISR and main loop are blocked by the EEPROM erasing.

I've done the same experiment on MC9S12XDG128, but everything is good.

Thanks again for your great help, the source code is attached.

Development  environment:

CodeWarrior Version 10.6 Build Id: 140329

C Build tool versions 4.7.3

Processor Expert Version 10.6.0 Build: RT6_b1446-0504

Regards,

Morty