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.

LAUNCHXL-F280049C: Fapi ECC data buffer error

Guru 55913 points
Part Number: LAUNCHXL-F280049C
Other Parts Discussed in Thread: MOTORWARE

Hello,

Excerpt from previous thread:

"There seems to be other bugs such as program async sectors with DCSM zones 1 or 2 flash sectors 12-15 proven unsecure. FAPI will not write any data to 64bit aligned Flash sectors. Even when they are confirmed to be 32bit blank checked and CCS debug Memory Browser shows (0xFFFF.FFFF).  The first sector address (10 bytes) to program flash start address (0x009C000), also blank checked 0x1000 (4096) 32-bit length." 

It seems there are other issues with FAPIi that need to be addressed via x49c FSM unsecured DCSM zones access. Even trying to program a sector with only 10 bytes length with only the first byte being changed produces the data bus error shown below. The pointer buffer length was set low (10) as to single step F5/F6 CCS debug to trouble shoot odd data bus error. This issue may be due to writing FPU floating point (float32_t or float) data into puc16DataBuffer via ECC program command, though debug goes several F5 steps into the command.

Why does the data buffer length error (20 bytes) cause FAPI error, never writes anything to FSM sectors after several debug F5 steps occur? The FSM does not seem to be commanded to write the sector data perhaps the most plausible cause? The flash memory cache was disabled prior to innating flash banks 0/1 for ECC writes shown below code snip. Though it does not seem necessary to claim FAPI semaphore for unsecure memory zones 1 or 2, neither semaphore zone works to allow ECC commanded sector program via FSM. 

    /* FAPI requires FLSEM Bank1/2 zone 1/2 secured writes.
     * Allow Zone1/2 writes in Flash Wrapper FSM registers */
    DCSM_claimZoneSemaphore(DCSM_FLSEM_ZONE1);
    //
    SCIprintf(">> DCSM Claim Flash Semaphore: Zone1 \n\n");
    
    /* disable the flash cache */
    Flash_disableCache(FLASH0CTRL_BASE);
    
    //
    // Call Flash Initialization to setup flash waitstates. This function must
    // reside in RAM.
    Flash_initModule(FLASH0CTRL_BASE, FLASH0ECC_BASE, DEVICE_FLASH_WAITSTATES);

    Flash_enableECC(FLASH0ECC_BASE);
    
    /* enable the flash cache */
    Flash_enableCache(FLASH0CTRL_BASE);


	/* Delay 200ns */
	SysCtl_delay(20);

    /* Initialize FSM FAPI flash parameter block driver. */
    FlashPBInit(FLASH_PB_START, FLASH_PB_END, FLASH_PB_SIZE);

 

  •  FAPI must be able to save (float32_t or float) data from the FPU or it is a useless API for saving motor control parameter floating point data for the EV or industrial motor drives industries. The motor control SDK 4.01, universal motor control SDK were designed specifically to use FPU float32_t parameters. FAPI program command input data buffer (uint16_t) is primitive and needs to evolve from 2017 last update Version 1.56.01.00. My reason for FAPI being required for remote updates of individual specific motor parameters, not the entire firmware. TI has diverged from older Motorware MCU classes, there is no alternative way to write 32-bit floating point ECC parameter data other than FAPI.