TMS320F28388D: Flash Erase

Hi Naresh,

From below datasheet spec, how did you arrive at 500us timeout that you mentioned?

You are using 0xF wait-states.  You can use 3 wait-states at 200MHz.  Any reason for you to not take this benefit?

Thanks and regards,

Vamsi

Hi Vamsi, 

I will be writing 15 bytes of data into Flash memory each 500 us, i do not see any issue in programming , its programming the flash memory accordingly.

I have tried with 0x3 wait-states  at 200MHz but i see the same behaviour so i tried with 0xF to see if there will be any improvement.

thanks,

Nagesh

Nagesh,

Ok, that time is for program - got it.  It was not clear in your previous post.

Are you saying that erase is taking longer for some sectors (but within the datasheet spec)?

Thanks and regards,
Vamsi

Hi Vamsi, 

Yes, i am ok if erase takes longer time until i am able to refresh my external watchdog which is connected to GPIO-46 and i need to refresh it less than 7ms.

So implemented a cpu timer 2 interrupt at every 5ms to refresh or toggle the GPIO-46 every interrupt. i verified the interrupt is working fine but i still see the during erasing the sector 4,5,6,7,8,9 second time it causes a reset which is because external WD is not refreshed.

The same code when ext WD is disabled works fine, i did perform timing analysis for the execution of Flash api functions where i could see it takes around 3 us each time its called

function : Fapi_issueAsyncCommandWithAddress(Fapi_EraseSector,(UINT32 *)u32FlashSectorAddr) - 3 us

Function : Fapi_checkFsmForReady(); - 1 us

Function : Fapi_doBlankCheck() :- 4.327 ms

thanks,

Nagesh

Nagesh,

Can you send me your linker cmd and map file?

You can send them offline if you have any proprietary info in there.

Thanks and regards,

Vamsi

Nagesh,

I received the map file. I don't see any issue with flash API usage. How about functions that call the flash API - Are they also executed from RAM?

Thanks and regards,
Vamsi

Hi Vamsi, 

Yes all the flash api functios are being executed from RAM. 

Can you let me know if we can interrupt the CPU1 or 2 when flash erase is being performed so that i can perform ext WD Refresh.

Does it work only on power up for erase operation and not later by interrupting ?

thanks,

Nagesh

Hi Nagesh,

Yes, CPU1/2 can be interrupted during the flash operations at any time.  You did not answer my previous question - How about the functions that call the flash API - Are they also executed from RAM?  They should be executed from RAM.

Can you confirm that there is no any kind of flash access during the interrupt?

Thanks and regards,

Vamsi

Hi Vamsi,

 How about the functions that call the flash API - Are they also executed from RAM?

Yes all functions which call Flash Api , i have ensured are executing from RAM.

Can you confirm that there is no any kind of flash access during the interrupt?

Yes, there is no Flash access in interrupt.

Thanks,

Nagesh

Nagesh,

Where is the timer interrupt located?

Thanks and regards,
Vamsi

Hi Vamsi,

i have configured the interrupt CPU timer 2 for 1 ms to only refresh the GPIO-46.

CPU timer 2 is configured with this RefreshWD function call.

#pragma DATA_SECTION(strGpioDataRegs,"GpioDataRegsFile");
volatile struct GPIO_DATA_REGS strGpioDataRegs;

void RefreshWD(void)

{

if(CPUID_1 == gu16CpuId)
{
EALLOW;

strGpioDataRegs.GPBSET.bit.GPIO46 = 1;

asm(" RPT #200||NOP");

strGpioDataRegs.GPBCLEAR.bit.GPIO46 = 1;

EDIS;

}

}

Thanks,

Nagesh

Nagesh,

Where is this function located?

Thanks and regards,
Vamsi

hi Vamsi, 

This function is location in flash which will be sector 0 to 3 and not beyond it.

thanks,

Nagesh

Nagesh,

Is this not copied to RAM?  If I understand correctly, this will be executed when flash erase/program operations are active in your application - correct?

Thanks and regards,
Vamsi

Hi Vamsi,

Yes, as of now in code this is not copied to RAM which refreshes the ext watchdog,

Yes this will be active when erase/program operations are active in my application, but i am not erasing this sector where the application is residing. the same code works fine when Ext WD is disabled.

I have a pending activity to measure the voltage output from GPIO-46 which should be 3.3v when erase operation is going on .i will let know about this.

thanks,

Nagesh

Nagesh,

As mentioned in the guide and discussed previously with you, no function should be executed from flash (any sector) when there is a erase or program operation is in progress.  Please copy it to RAM.

Thanks and regards,
Vamsi

Hi Vamsi, 

I have created a similar issue what i am observing using Internal WD, which is enabled and i am servicing the internal watchdog every 6ms.

I have modified the example program 'flashapi_ex1_programming' accordinly added a function call to erase sector 7,8,9 and program sec 7,8,9 and erase sec 7,8,9 again . during the second time erase of sector even though the internal watchdog is serviced i could see the internal watchdog was not serviced intime and got interrupted during the second erase operation of flash sector 7,8,9.

Below function calls i have added in sequence

Eraseallsectors();

Prgsector();

Eraseallsectors();  -> Fails here when internal WD is not serviced.

I have also updated the sysctl.h file to enable Internal WD with different timed interrupts, I have verified the erase operation for 6ms, 13ms and 26ms and my observation is as below 

When internalWD was tried to service at 6ms the erase operation failed and stopped at Interrupt  - FAILED at 6ms

When internalWD was tried to service at 13ms the erase operation failed and stopped at Interrupt - FAILED at 13ms

When internalWD was tried to service at 26ms the erase operation worked fine. - PASSED at 26ms

Basically i am interested to know why it fails at 6ms and how can we address this. if there is a limitation please let me know.

#define SYSCTL_WD_CHKBITS_6MS 0x0C2CU
#define SYSCTL_WD_CHKBITS_13MS 0x0C2DU
#define SYSCTL_WD_CHKBITS_26MS 0x0C2EU

and function is updated as below 

static inline void

SysCtl_enableWatchdog(void)
{
uint16_t sysctl_wd_Chkbits = SYSCTL_WD_CHKBITS;

sysctl_wd_Chkbits = SYSCTL_WD_CHKBITS_6MS;
//sysctl_wd_Chkbits = SYSCTL_WD_CHKBITS_13MS;
//sysctl_wd_Chkbits = SYSCTL_WD_CHKBITS_26MS;

EALLOW;

//
// Clear the disable bit.
//
HWREGH(WD_BASE + SYSCTL_O_WDCR) = (HWREGH(WD_BASE + SYSCTL_O_WDCR) &
~SYSCTL_WDCR_WDDIS) | sysctl_wd_Chkbits;

EDIS;
}

I will share you the example project file to debug as i am not able to attach here.

thanks,

Nagesh

Nagesh,

Can you confirm that you fixed my previous finding?  -> Did you move the watchdog servicing code/ISR to RAM now?  And still see this issue?

Thanks and regards,
Vamsi

Hi Vamsi, 

Yes, i have moved all the functions to RAM now. including the ISR.

thanks,

Nagesh

Nagesh,

Thank you for the info.  I will be able to take a look in to your code mid next week.

Thanks and regards,
Vamsi

Nagesh,

It would be better to meet on a webex call - that helps to review other components of the project.

Let me know if that is fine with you.  If you are ok, we can align on date/time.

Thanks and regards,
Vamsi

FYI for others:  We are discussing this offline as we are reviewing Nagesh's custom proprietary code.

Thanks and regards,
Vamsi