TMS320F28377D: After CPU2 adds Flash read operation which works every 25 seconds, CPU1 resets every 4 seconds when the power is turned off and then turned on.

Hi Jim,

Jim Chen (SEM) said:

My customer wants to achieve a function that cpu2 writes a set of data (from cpu1) to flash every 25 seconds, and the amount of data is small (maybe 16 bytes). The design life of the system should be 25 years, is this feasible?

It may be possible, but the Write / Erase cycles and retention specifications need to be considered for the application.

Jim Chen (SEM) said:

After the programming is completed, turn off the power for the first time and turn it on again, and the MCU will work normally. When the power is turned off for the second time and turn it on then, CPU1 resets every 4 seconds and CPU2 don't work. It is the same when powering off and on again later, until it is reprogrammed.

How are they verifying that CPU1 is resetting and CPU2 isn't working? They are not connected to the device over JTAG after power-cycling the device, correct?

Jim Chen (SEM) said:

The customer tests that if the read Flash operation is not added, the MCU will always work normally when the power is turned off and then turned on again. If read operation is added, the above problem will appear. So they suspect that there is a problem with the read operation. 

This is just when adding the read function shown? There's no other conditional code included along with this?

Best,

Kevin

Hi Kevin,

Thanks a lot for your reply.

Kevin Allen18 said:

How are they verifying that CPU1 is resetting and CPU2 isn't working? They are not connected to the device over JTAG after power-cycling the device, correct

Yes, they connect the board to a display screen that would show a continuously increasing count when the program is working normally, and clear to zero when reset. Therefore, the customer judges that cpu1 resets every 4 seconds. At the same time, the screen will also display the result of cpu2 reading flash, which is used to judge whether cpu2 is working normally.

Kevin Allen18 said:

This is just when adding the read function shown? There's no other conditional code included along with this?

In the cpu2 code, the flash erase and program operation will not affect the normal operation of the system, and the above-mentioned phenomenon will appear after adding the read operation. 

The customer reported that there has been a problem with the read function (Fapi_doMarginRead()) in the API, so the mentioned code is used for the read operation. The strange thing is that the system works normally after the first power off and then on after the programming is completed. The reset phenomenon starts from the second power off and then on. Will power off affect the operation of the flash?

Do we have an example code of Fapi_doMarginRead() useage or can we provide the source code of the read function? And is there any problem with reading flash directly by address? 

My customer and I have a relatively preliminary understanding of the use of flash, but the project is a little urgent. Thank you so much for your generous answers to my so many questions.

Best Regards,

Jim

Hi Jim,

This is assigned to me for review.

I will be able to review and get back to you early next week.

Thanks and best regards,

Vamsi

Hi Jim,

Please clarify:  Is the application reading the flash space that is programmed by the application at run time?  If yes, what programming mode is used by the application?  

There is no any issue in reading the flash addresses directly.  

pu32ReadBuffer is the address of the buffer where the function returns the data.

Thanks and regards,
Vamsi

Hi Vamsi,

Thanks for your reply!

Vamsi Gudivada said:

Is the application reading the flash space that is programmed by the application at run time?

Yes, and the programming code is shown below:

Flash0EccRegs.ECC_ENABLE.bit.ENABLE = 0x0;

for(i=0, u32Index = Bzero_SectorC_start;

   (u32Index < (Bzero_SectorC_start + WORDS_IN_FLASH_BUFFER)) &&

   (oReturnCheck == Fapi_Status_Success); i+= 8, u32Index+= 8)

{

    oReturnCheck = Fapi_issueProgrammingCommand((uint32 *)u32Index,

                                                Buffer+i,

                                                8,

                                                0,

                                                0,

                                                Fapi_DataOnly);

And, the reading code is that:

#pragma CODE_SECTION(Example_CallFlashRead, ramFuncSection);
void Example_CallFlashRead(void)
{
uint32 u32Index = 0UL;
uint16 i = 0U;

 for(i=0, u32Index = Bzero_SectorC_start;(u32Index < (Bzero_SectorC_start + WORDS_IN_FLASH_BUFFER)); i+= 1, u32Index+=1)

 {

    *(ReadBufferCB+i) = *(uint16 *)u32Index;

 }

}

Is there any issue? And if it is being erased or programmed when the power is turned off, will it affect the normal work when it is powered on next time? I find that the customer erases the Sector every 25 seconds and then programme.

The erasing code is that:

oReturnCheck = Fapi_issueAsyncCommandWithAddress(Fapi_EraseSector,

               (uint32 *)Bzero_SectorC_start);

while(Fapi_checkFsmForReady() != Fapi_Status_FsmReady){}

Best regards,

Jim

Hi Jim

Looks like they are not programming ECC.

Maybe they can try disabling ECC before the reads - let me know how this goes.

Also, as requested offline: Can you move this to external forum?

Thanks and regards,
Vamsi

Hi Vamsi,

They disable ECC before programming by (Flash0EccRegs.ECC_ENABLE.bit.ENABLE = 0x0;). Can that work?

Vamsi Gudivada said:

Can you move this to external forum?

Sure, The codes are basically derived from examples, but i don't know how to transform. Maybe you can move this to external forum directly?

Thanks a lot!

Jim

Hi Vamsi,

Thanks for your suggestion! I have advised my customer to replace Fapi_DataOnly with Fapi_AutoEccGeneration. Maybe tomorrow they will have testing results. Will ECC error lead to CPU1 keep resetting?

Thanks and regards,

Jim

Hi Jim,

Yes, ECC error can cause the resets.

Thanks and regards,

Vamsi

Hi Vamsi,

The customer replied that the reset problem has been fixed. Thanks a lot for your help!

Best regards,

Jim

Hi Jim,

Glad it helped.  I am closing this post.

Thanks and regards,

Vamsi