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.

TMS570LS0714: Bank 7 Erase Problem

Part Number: TMS570LS0714

Tool/software:

Hello,

I am having issues with erasing and reprogramming the emulated EEPROM area using the F021 library on TMS570LS0714. All API calls return success, but nothing is being erased at address 0xF0200000.

When I include this code in the main function and flash it as the main project, it works with no issues. However, I need to implement this function as a part of an existing project as a secondary project - a small software module that is downloaded over CAN (to flash, not RAM) and executed by the main software. When this is the case it doesn't erase anything.

I'm trying to understand if there is something that protects the bank 7 or prevents it from being erased (in the reference manual SPNU607A and the F021 reference guide SPNU501H) but could not find anything. FBBUSY value before erase is 0x7E which means bank 7 is not busy. I checked the flash pump registers and the fallback power register FBFALLBACK and all pumps are active.

I also tried disabling the IRQs and FIQs before the operation but didn't help.

Below is my code:

#include "sys_common.h"
#include "F021.h"
#define SYS_CLK_FREQ 160

int myFunction(void) {
  Fapi_initializeFlashBanks((uint32_t) SYS_CLK_FREQ);
  Fapi_setActiveFlashBank((Fapi_FlashBankType)7);

  while (FAPI_CHECK_FSM_READY_BUSY != Fapi_Status_FsmReady);

  Fapi_enableEepromBankSectors(0xFFFFFFFF, 0xFFFFFFFF);
  while (FAPI_CHECK_FSM_READY_BUSY != Fapi_Status_FsmReady);

  uint32_t i;
  for (i = 0; i < 16; i++) {
    Fapi_issueAsyncCommandWithAddress(Fapi_EraseSector, (void*)(0xF0200000 + 0x1000 * i));
    while (FAPI_CHECK_FSM_READY_BUSY == Fapi_Status_FsmBusy);
    while (FAPI_GET_FSM_STATUS != Fapi_Status_Success);
  }
}

The code just runs "fine" all the way to the end as if everything was good, but has zero effect.

Any help would be greatly appreciated. Thanks.

---

Edit:

While diagnosing the issue I wanted to do some manual tries on flash registers and I realized the lines below don't do anything (supposed to edit the WR_ENA register)

uint32_t preVal = *(volatile uint32_t *)0xFFF87288;
*(volatile uint32_t *)0xFFF87288 = (preVal & 0xFFFFFF00) | 0x05;
*(volatile uint32_t *)0xFFF87288 = (preVal & 0xFFFFFF00) | 0x02;

and also these don't work:

FLASH_CONTROL_REGISTER->FsmWrEna.FSM_WR_ENA_BITS.WR_ENA = 0x5U;
FLASH_CONTROL_REGISTER->FsmWrEna.FSM_WR_ENA_BITS.WR_ENA = 0x2U;

So turns out being in the user mode is preventing the code from modifying the memory.

  • Hi Nail,

    I verified and tested your code and i don't see any issues in it.

    I added your code to one of my existing projects where i am writing some data at the 0xF0207010, and here is the data before executing your code:

    And after executing your code, the written data erased successfully, like as below.

    I think this code should also work even if you use as secondary project. I want to know the following things:

    1. Where you are trying to store the secondary project in the flash? Is it possible to share the linker cmd files for both while using main project and secondary project?

    2. Why don't you verify wiring data and reading data as well instead of only erasing?

    3. I hope you already aware of the some of the bits in the flash will be 0 instead of 1 even after erasing the flash, i explained reason for this in the below thread:

    (+) TMS570LC4357: Uniflash tool could not erase the flash memory correctly. - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

    However, this will not affect our writing and reading into the flash.

    --
    Thanks & regards,
    Jagadish.

  • Hi Jagadish,

    Thanks for all the detailed information and verifying the code. The code was correct, I was having the issue because the erase code was not running in the privileged mode. Once I switched to supervisor mode with the SVC call it all worked well.