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.

TMS570LS3137: The bootloader is programd and the internal flash cannot be read

Part Number: TMS570LS3137


Hi team,

Here's an issue from the customer may need your help:

The bootloader currently uses bank0 for the IAP program, bank1 for the app program, and external memory for the firmware package when upgrading the programming. There are 2 problems with the upgrade: 

1) Erase on IAP upgrade, call the function uint32_t Fapi_BlockErase( UINT32_t Bank, UINT32_t ulAddr, UINT32_t size). Unable to read function status = Flash_Erase_Check((uint32_t)ulAddr, size), monolithic exception occurred after execution. 

2) After programing UINT32_t Fapi_BlockProgram( UINT32_t Bank, UINT32_t Flash_Address, UINT32_t Data_Address, UINT32_t. SizeInBytes), and executing UINT32_t Flash_Program_Check(UINT32_t Program_Start_Address, UINT32_t Source_Start_Address, UINT32_t. No_off_bytes), the monolithic cannot work properly.

The IAP program link script is configured as follows: 

MEMORY
{
VECTORS (X) : origin=0x00000000 length=0x00000020
FLASH_API (RX) : origin=0x00000020 length=0x000014E0
FLASH0 (RX) : origin=0x00001500 length=0x00180000-0x00001500
// FLASH1 (RX) : origin=0x00180000 length=0x00180000
STACKS (RW) : origin=0x08000000 length=0x00001500
RAM (RW) : origin=0x08001500 length=0x0003EB00

/* USER CODE BEGIN (2) */
/* USER CODE END */
}

/* USER CODE BEGIN (3) */
/* USER CODE END */


/*----------------------------------------------------------------------------*/
/* Section Configuration */

SECTIONS
{
.intvecs : {} > VECTORS

flashAPI :
{
..\Debug\F021\source\Fapi_UserDefinedFunctions.obj (.text)
..\Debug\F021\source\bl_flash.obj (.text)
--library=..\F021\F021_API_CortexR4_BE.lib < FlashStateMachine.IssueFsmCommand.obj
FlashStateMachine.SetActiveBank.obj
FlashStateMachine.InitializeFlashBanks.obj
FlashStateMachine.EnableMainSectors.obj
FlashStateMachine.IssueFsmCommand.obj
FlashStateMachine.ScaleFclk.obj
Init.obj
Utilities.CalculateEcc.obj
Utilities.WaitDelay.obj
Utilities.CalculateFletcher.obj
Read.MarginByByte.obj
Read.Common.obj
Read.FlushPipeline.obj
Read.WdService.obj
Async.WithAddress.obj
Program.obj > (.text)
} load = FLASH_API, run = RAM, LOAD_START(api_load), RUN_START(api_run), SIZE(api_size)

.text : {} > FLASH0
.const : {} > FLASH0
.cinit : {} > FLASH0
.pinit : {} > FLASH0
.bss : {} > RAM
.data : {} > RAM
.sysmem : {} > RAM

/* USER CODE BEGIN (4) */
/* USER CODE END */
}

Could you help check this case? Thanks.

Best Regards,

Cherry

  • Hi Cherry,

    From your LInker CMD file, you will program your firmware to bank 0 (same bank as the bootloader).

    If programming the firmware to the same bank, you need to copy the Flash APIs and related code to SRAM, and execute those code from the SRAM.

    Please copy the .text and .data to SRAM:

    flashAPI :
    {
    ..\Debug\F021\source\Fapi_UserDefinedFunctions.obj (.text, .data)
    ..\Debug\F021\source\bl_flash.obj (.text, .data)
    --library=..\F021\F021_API_CortexR4_BE.lib (.text, .data)
    } load = FLASH_API, run = RAM, LOAD_START(api_load), RUN_START(api_run), SIZE(api_size)

  • Hi,

    Thanks for your help.

    Instead of programming into the same bank, the customer stores bootloader via bank0 and the app via ban1.

    When program to ban1 in ban0, it's find that it cannot read the data for ban1. The linker cmd written above is for the bootloader program.

    If they program subsequent projects in the same bank, linker cmd would modify it as you suggested, right?

    Thanks and regards,

    Cherry

  • If they program subsequent projects in the same bank, linker cmd would modify it as you suggested, right?

    Yes. 

    If you program the application to bank1, it is fine to run flash APIs out of bank 0.

  • Hi,

    If you program the application to bank1, it is fine to run flash APIs out of bank 0.

    How does the linker cmd of the bootloader need to be modified?

    The customer's bootloader code also calls _copyAPI2RAM_() before the _c_int00 function calls the main function.

    Thanks and regards,

    Cherry

  • Hi Cherry,

    Using the original linker cmd file, the _copyAPI2RAM_() only copies the .text section from flash to SRAM. 

    I'd like to copy the flash sector defined in flash_defines.h. If you use the modified linker cmd mentioned in my last message, the const for flash_sector should be removed:

    flashAPI :
    {
    ..\Debug\F021\source\Fapi_UserDefinedFunctions.obj (.text, .data)
    ..\Debug\F021\source\bl_flash.obj (.text, .data)
    --library=..\F021\F021_API_CortexR4_BE.lib (.text, .data)
    } load = FLASH_API, run = RAM, LOAD_START(api_load), RUN_START(api_run), SIZE(api_size)

    #if defined (TMS570LS07) || defined (RM44)
    #define NUMBEROFSECTORS 12
    const SECTORS flash_sector[NUMBEROFSECTORS]=
    {

  • Unable to read function status = Flash_Erase_Check((uint32_t)ulAddr, size), monolithic exception occurred after execution. 

    To check the blank flash sector, the flash ECC should be disabled. Otherwise you will get uncorrectable ECC error and data abort.

  • executing UINT32_t Flash_Program_Check(UINT32_t Program_Start_Address, UINT32_t Source_Start_Address, UINT32_t. No_off_bytes), the monolithic cannot work properly.

    Is the ECC programmed using Fapi_issueProgrammingCommand()?

    Is No_off_bytes in your Flash_Program_Check(..) the same as the size of your application image? If No_off_bytes is > the length of your application image, your Flash_Program_Check(..) will read flash data (0xFFFFFFFF FFFFFFFF) with invalid ECC value (0xFF).