This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Fapi write issue running from flash

Hi

I am seeing some strange issues using the Flash API on my F28377D. When I am connected to the debugger, everything seems to be working fine. I can write my data file to flash with my software. However, when I disconnect the debugger and boot from Flash, the same software does not work. It only makes it through the erase command and then crashes at the Fapi_issueProgrammingCommand call. I thought this may be an issue where the Fapi was not running from Flash but it confuses me why the erase would work and the write would not.

First my command script should point the ramfuncs and API lib to run from ram and then in my init I use the memcpy below to move data to ram.

/* Guarantee that Flash API runs from RAM*/
    GROUP
    {
        ramfuncs
        { -l F021_API_F2837xD_FPU32.lib}

    } LOAD = FLASHA | FLASHB | FLASHC | FLASHD | FLASHE |
             FLASHF | FLASHG | FLASHH | FLASHI PAGE = 0
      RUN  = RAMGS5|RAMGS6 PAGE = 1
      LOAD_START(_RamfuncsLoadStart),
      LOAD_SIZE(_RamfuncsLoadSize),
      LOAD_END(_RamfuncsLoadEnd),
      RUN_START(_RamfuncsRunStart),
      RUN_SIZE(_RamfuncsRunSize),
      RUN_END(_RamfuncsRunEnd)

memcpy(&RamfuncsRunStart, &RamfuncsLoadStart, (UINT32)&RamfuncsLoadSize);

Next we initialize flash(note that this happens before starting the BIOS)

  //Must be run out of RAM
  EALLOW;
  InitFlash();

  //Disable ECC
  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
  Fapi_initializeAPI(F021_CPU0_BASE_ADDRESS, 200);

  //Set Flash bank to CPU1(FB0)
  Fapi_setActiveFlashBank(Fapi_FlashBank0);

  EDIS;

Finally during runtime I call flash_erase and flash_write in order below

Status_Type flash_erase
  (
  UINT32 start_address
  )
{
  EALLOW;

  // Erase sector from start address
  Fapi_issueAsyncCommandWithAddress(Fapi_EraseSector,
      (UINT32 *)start_address);

  monitor_log_message("Erase command sent");

  // Wait until FSM is done with erase sector operation
  while (Fapi_checkFsmForReady() != Fapi_Status_FsmReady){}

  monitor_log_message("Erase completed");

  EDIS;
  return Status_Success;
}
Status_Type flash_write
  (
  UINT32    start_address,      /* In: Address in flash to start writing to. */
  UINT16    *buffer,            /* In: Pointer of data buffer to be written */
  UINT32    num_bytes_to_write  /* In: Number of bytes to write */
  )
{
  UINT32 i = 0;
  EALLOW;

  for(i = 0; i < (num_bytes_to_write/2); i++)
  {
    monitor_log_message("Programming command sending");
    Fapi_issueProgrammingCommand(
        (UINT32 *)start_address+i,
        buffer+(2*i),
        0x2, //Write 32 bits at a time
        0,
        0,
        Fapi_DataOnly);

    monitor_log_message("Programming command sent");

    while(Fapi_checkFsmForReady() == Fapi_Status_FsmBusy){}
  }

  EDIS;

  return Status_Success;
}

Any help would be appreciated. I am lost for ideas on what to try next to get past this issue. I have my workaround for now so that I can write flash with the debugger open and then just read the data I need while software is running but we would like to be able to load data into flash on the fly while running without having to connect the debugger.

-Matt

  • Hi Brett,

    I followed that setup checklist previously. I can successfully run all of my code besides the Fapi_issueProgrammingCommand() when running from Flash. I can successfully see my system boot and I can control all the peripherals. I trigger the flash erase and write from an external message that comes in. I see the message come across from the test tool and that triggers an erase followed by a write of the message data. The erase works fine I see it get called and it continues on to trying to write. Then once it enters the Fapi_issueProgrammingCommand it crashes.

    I believe that the Fapi_issueAsynchCommand is in the same memory sector(RAM) as Fapi_issueProgrammingCommand so I don't understand why one command works and not the other. And my big issue with trying to isolate the issue is that I cant breakpoint in the debugger because the system works correctly when I am connected to that.

    -Matt
  • And everything works correctly if you follow the "Load Symbols Only" path with the debugger?  (described in my previous post)

  • I apologize...I wasn't following those steps completely. When I run with the load symbols only path from that document, I see an error

    [C28xx_CPU1] ti.sysbios.family.c28.Hwi: line 1013: E_unpluggedInterrupt: Unplugged interrupt flagged: intr# 19
    xdc.runtime.Error.raise: terminating execution

    I verified all of the addresses of the Fapi calls and they all appear to be in RAM. I am not sure where the unplugged interrupt comes from. I can break point at the while loop in the flash write code below but when I try to step past that I hit the error. Any ideas on what would cause that? I dont know if the error is generated by the IssueProgrammingCommand or the checkFsmForReady function.

    Fapi_issueProgrammingCommand(
            (UINT32 *)start_address+i,
            buffer+(2*i),
            0x2, //Write 32 bits at a time
            0,
            0,
            Fapi_DataOnly);
    
    while(Fapi_checkFsmForReady() == Fapi_Status_FsmBusy){}

  • Argiro,

    Can you add an EALLOW before below code?  InitFlash() function has an EDIS at the end and hence below API functions will not be able to initialize the Flash correctly.

    //Disable ECC

    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

    Fapi_initializeAPI(F021_CPU0_BASE_ADDRESS, 200);

    //Set Flash bank to CPU1(FB0)

    Fapi_setActiveFlashBank(Fapi_FlashBank0);

    Thanks and regards,
    Vamsi

  • Matthew,

    Are you able to erase and program successfully now?

    Thanks and regards,
    Vamsi

  • Matthew,

    I am closing this thread for now assuming that you are able to erase/program fine now.  You can reopen the thread if needed.

    Thanks and regards,
    Vamsi