TMS320F28377D: GPIO's driven High/Low and system hanging during flash erase operation.

Hi Ugnius,

I am working on getting you in touch with one of our flash programming experts for this device.

Regards,
Kris

Ugnius,

Here are some ideas for your debug: 

1) Table 5-20. Flash Parameters at 200 MHz in DataManual says that the typical erase time is 110 ms (considering 32KW sector).  Did you consider this spec when deciding the rate at which you should service the watchdog?   

2) As mentioned in the TRM, Flash API is interruptible.  Hence, you can service the watchdog via an interrupt even when the Flash API execution is in progress.  Hope you are aware of this.  However, there should not be any read/fetch access from the Flash bank on which an erase/program operation is in progress.  Hence, you should have your ISR in RAM.

3) Did you make sure that you are not erasing the Flash sector that has Flash API in it?  Do you have an ITRAP handler?  Did you try to toggle a GPIO from that handler?  May be your application is trying to execute something from erased flash and hence got an ITRAP and stuck in the ITRAP handler's infinite loop leading to watchdog reset?     

4) Did you map the functions in the Fapi_UserDefinedFunctions.c to RAM for runtime execution?  They are supposed to be mapped to .TI.ramfunc section.

5) You may already know.  But wanted to mention again that the Flash API does not configure (enable/disable) watchdog. The user application can configure watchdog and service it as needed.  Fapi_serviceWatchdogTimer() function provided in Fapi_UserDefinedFunctions.c is called only in the Fapi_doVerify() and Fapi_doBlankCheck() functions as mentioned in the Flash API reference guide.

Thanks and regards,
Vamsi

Hi Vamsi,

Thanks for your reply.

1. The watchdog is serviced before flash operation. It takes 800 ms for watchdog to expire.

2-3.  Code is running from FLASH B, E ,F ,G. I am erasing and writing to sectors C, H, I, J and A.

4. The .cmd memory allocation is shown in "FAPI memory allocation" reply below.

5. The expired watchdog is not the issue.

After further investigation of the problem I found that problem is caused by setting up the FAPI rather than erasing flash.

Looking at the example of erasing and writing to flash I split code to functions.

The function that causes problem is in "Failing function" reply below.

I call this function before trying to erase anything.

Sometimes it crashes executing function Fapi_setActiveFlashBank(Fapi_FlashBank0);

At which point GPIOs are driven to different states. The normal code stops executing and as watchdog is not serviced processor restarts. The crash itself is not the problem as watchdog resets processor. The problem is GPIOs changing their state. The scope of affected pins is not known as I observed different GPIOs driven high for different time period. This can cause damage if turned on un-timely when sensitive hardware is connected.

I added GPIOs and DAC manipulation to indicate what is happening.

When function works The correct signals are observed:

yellow - DAC A. (To add delay and indicate when Fapi_initializeAPI finishes and Fapi_setActiveFlashBank start.)

green - DAC B. (To add delay and indicate when Fapi_setActiveFlashBank finishes and function exits.)

blue - GPIO70. (Just a test point)

purple - GPIO4. (A pin that can be configured as PWM output.).

When it crashes a strange GPIO behavior is observed:

 

It looks like Fapi_setActiveFlashBank(Fapi_FlashBank0) never finished executing as DAC B is never ramped up.

Also the other GPIOS go low or high which is not set in code.

In standalone mode the code runs and reboots at a period of 2.5s.

After starting code this glitch occurs within 5 minutes. Sometimes sooner, sometimes later.

Some points to note:

1. Changing DAC ramp between functions Fapi_initializeAPI(F021_CPU0_BASE_ADDRESS, 200); and Fapi_setActiveFlashBank(Fapi_FlashBank0); to above 80ms seem to eliminate the glitch or reduce the likelihood such that I dont see it within the test time.

2. Disabling interrupts while Flash_operation_init(void) function runs seems to stop glitch from happening.

The only interrupt that is running is a 25us timer interrupt that increments some counters. I have i2c and spi modules initialised and interrupts set up but they are configured for slave operation and are not running.

Fapi functions are from library thus I cannot see what they do and debug it further.

If timer interrupt happens during Fapi_setActiveFlashBank(Fapi_FlashBank0); execution, would that cause a problem (ISR runs from flash)?

 

"FAPI memory allocation"

// RAMLS3 : origin = 0x009800, length = 0x000800
// RAMLS4 : origin = 0x00A000, length = 0x000800
RAMLS34 : origin = 0x009800, length = 0x001000
// FLASHF : origin = 0x090000, length = 0x008000 /* on-chip Flash */
FLASHF1 : origin = 0x090000, length = 0x000100 /* on-chip Flash */
FLASHF2 : origin = 0x090100, length = 0x000500 /* on-chip Flash */
FLASHF3 : origin = 0x090600, length = 0x002600 /* on-chip Flash */
FLASHF4 : origin = 0x092C00, length = 0x005400 /* on-chip Flash */

GROUP
{
fapifuncs { -l F021_API_F2837xD_FPU32.lib }
}
LOAD = FLASHF3,
RUN = RAMLS34,
RUN_START(_FapifuncsRunStart),
LOAD_START(_FapifuncsLoadStart),
LOAD_SIZE(_FapifuncsLoadSize),
PAGE = 0

ramfuncs : LOAD = FLASHF1,
RUN = RAMLS34,
RUN_START(_RamfuncsRunStart),
LOAD_START(_RamfuncsLoadStart),
LOAD_SIZE(_RamfuncsLoadSize),
PAGE = 0

"Failing function"

void
Flash_operation_init(void)
{
  uint16_t test_ind;
  SeizeFlashPump();
  GpioDataRegs.GPCSET.bit.GPIO70 = 1;
  EALLOW;
    Flash0EccRegs.ECC_ENABLE.bit.ENABLE = 0x0;
    // This function is required to initialize the Flash API based on System
    // frequency before any other Flash API operation can be performed
    oReturnCheck = Fapi_initializeAPI(F021_CPU0_BASE_ADDRESS, 200);

    for(test_ind = 0; test_ind < 4096; test_ind++)
    {
      DacaRegs.DACVALS.bit.DACVALS = test_ind;
      DELAY_US(1U);
    }

    if (oReturnCheck != Fapi_Status_Success)
    {
      GpioDataRegs.GPCCLEAR.bit.GPIO69 = 1;
      GpioDataRegs.GPCSET.bit.GPIO70 = 1;
      DELAY_US(100000U);
      Example_Error(oReturnCheck);
    }

    GpioDataRegs.GPCSET.bit.GPIO71 = 1;
    // Fapi_setActiveFlashBank function sets the Flash bank and FMC ( Flash module Controller) for further
    // Flash operations to be performed on the bank
    oReturnCheck = Fapi_setActiveFlashBank(Fapi_FlashBank0);

    for(test_ind = 0; test_ind < 4096; test_ind++)
    {
      DacbRegs.DACVALS.bit.DACVALS = test_ind;
      DELAY_US(1U);
    }

    if (oReturnCheck != Fapi_Status_Success)
    {
      GpioDataRegs.GPCCLEAR.bit.GPIO69 = 1;
      GpioDataRegs.GPCSET.bit.GPIO70 = 1;
      DELAY_US(100000U);
      Example_Error(oReturnCheck);
    }
  EDIS;
  GpioDataRegs.GPCCLEAR.bit.GPIO71 = 1;
}

1. As can be seen in my last post with example code I use EALLOW first, then set ECC to 0 and then call other flash functions.

2. So if I have ISR (running from flash E) interrupt FLASH init function running from RAM this might cause a problem?

Thanks for the quick reply.

Point 2 seems to fix the issue. Also increasing timer frequency accelerates the glitch occurrence once ISR runs from flash.

Different GPIOs being driven when this happens is quite a dangerous glitch though.
I have GPIOs controlling H-bridge.
This glitch caused shoot-through damaging the FETs.

Can you explain how running ISR from flash during Fapi_setActiveFlashBank execution can corrupt GPIO registers driving some pins high?
Should there not be a built in handler for such illegal FLASH access within FAPI?

Thanks a lot for your help Vamsi.

This all makes more sense now.

Ugnius,

Glad to know that your application is working now. I am closing this thread.

Thanks and regards,
Vamsi