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.

TMS570LC4357: FAPI Flashloader in IAR EWARM clears flashpage after application

Part Number: TMS570LC4357

I am writing a bootloader for the TMS570LC437 which fits into 64 kB.
The IAR linker is configured to to fill any unused locations with 0xFF from 0..0xFFFF.
The map file shows there is nothing beween 0x10000 and 0x3FFFFF (end of flash).

The bootloader is downloaded to the flash using the IAR debugger.
The mechanism to program the flash is the standard IAR Flashloader,
which uses the F021_API library.

The result is that the flash sector following the bootloader (0x10000 to 0x1FFFFF) is all zeroed out.

If I set the linker to fill from 0x0 to 0x1FFFF, reserving 128kB for the bootloader,
the third flash sector (0x20000 to 0x2FFFFF) is all zeroed out.

====

The bootloader expects the application to reside in the flash sector following the bootloader.
If I link the application to 0x10000 with a 64kB bootloader, any code in the second
flash sector (0x10000 - 0x1FFFF) fails to program, since the contents are
all read out as zero.

====

Is the FAPI library doing something funny, like disabling flash sectors?

There is the Flash Bank Sector Enable Register (FBSE).
If the Flash Bank Sector Enable register somehow is used to disable a sector, then this could explain the symptom.
It is not explained in the reference manual what happens if you read from a disabled sector.
Will you get an abort, or will you read a fix value (like 0x00)?

I can also think about that the MPU generates problems.
I do not see whyt it should though.

Any other ideas what might go wrong?

  • Hello,

    You can erase the whole flash before you load the bootloader to flash. After flash is erased, the flash content becomes 0xFFFFFFFF. FBSE is used to prevent the flash sectors from program and erase rather than reading.

    The ECC values for all of the flash memory space (flash banks 0 through 6) must be programmed into the flash before the program/data can be read. This can be done by filling the whole flash to 0xFFFF and calculating/programming the ECC for the whole flash in your Linker cmd file.

    I am not familiar to IAR IDE and IAR linker cmd file.

  • You do not want to erase the whole flash, since then you erase the application.
    You want to program the controller in two steps which can come in any order.

    * Program 0..0xFFFF

    * Program 0x10000..0x3FFFFF

    When you program one area, you should not affect the other area.

    ====================================================

    While I am using the IAR toolchain, the programming is based on the FAPI library.
    (I expect that the IAR Debugger will only send erase and program commands for the 0..0xFFFF area.)

    Let me rephrase the question:

    If I use the F021 library and erase the 0x0..0xFFFF area, and then program it,
    Will this affect the use of the 0x10000..0x3FFFFF?

    Will it make it impossible to program any part of that area without a full erase.
    Will the F021 library refuse to program an area which is all zero?

    If you write to a sector and then protect the sector using FBSE, will you
    be able to read out what you programmed or will the protection cause
    you to read out a default value?


  • If I use the F021 library and erase the 0x0..0xFFFF area, and then program it, Will this affect the use of the 0x10000..0x3FFFFF?

    QJ> It will not affect the use of 0x10000~0x3FFFFF

    Will it make it impossible to program any part of that area without a full erase. Will the F021 library refuse to program an area which is all zero?

    QJ>It is impossible to program a value to a flash location whose content is zero.

    If you write to a sector and then protect the sector using FBSE, will you be able to read out what you programmed or will the protection cause
    you to read out a default value?

    QJ> The BSE is cleared by default. It prevents the flash from program/erase, but it doesn't affect the read operation. You will read out what you programed.

  • I finally figured out what went wrong.
    Apparently the programming mechanism of the IAR EWARM will do something similar to:

    1. Reset the part.
    2. Stop the execution and download a flashloader to SRAM.
    3. Run the flash loader, which communicates with the debugger.
    4. Reset the part
    5. Stop the execution and download a verification program.
    6. Run the verification program which compares the programmed memory with the expected memory.

    The problem seems to be that they let the CPU execute code after reset.
    This code can put the CPU into any kind of state.
    My bootloader copies itself to SRAM, and then enables the Parameter Overlay Module,
    mapping the first 64 kB of flash into SRAM.

    This appears to happen before the verification program is run, but the verification program
    clears the SRAM before it runs, so it reads out all zeroes.

    I ran into the the problem that after programming the first 64 kB and BEFORE executing anything,
    the first sector was all zeros. I then checked the POM register and the POM was enabled.
    Disabling the POM by writing to the register in the debugger, suddenly changed the first 64kB
    from all zeroes to suddenly contain the proper code.

    So the solution to the problem is to not let the CPU run any user code during the debugger downloading process.
    This may be impossible due to limitations in the Cortex-R5 JTAG interface.
    I do not know enough about the inner working to make a judgement.

    A workaround for the IAR EWARM which we will try is to use their macro facility
    to always disable the Parameter Overlay Module during flash programming.

    It might be worthwhile to check if the CCS is sensitive to such problems as well.