• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 29 subscribers
  • Views 198 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

TMS570LS1224: CAN Bootloader - Application Example Code

RM44L920: CAN Bootloader - Writing Magic Number To FlashBank7 Not Working

Thomas Green1
Prodigy 230 points
Part Number: RM44L920
Other Parts Discussed in Thread: HALCOGEN

I have this working on an RM46 XL2 LaunchPad, and had it working on a production board using the RM44L920, but I changed something (no idea what; though I moved to CCS v10 from v9) and the RM44 version is no longer writing value 0x5A5A5A5A to location 0xF020F000. 

The BootLoader (BL) loads onto the production board via JTAG with no issues, and the CAN update appears to go through just fine. Since the 0xF020F000 memory location is not being modified at the end of the update, the chip goes back into the BL. I can modify the RUN address in the host updater code and run my application until a reset or power cycle occurs, but that's not terribly useful.

I added a line to send the result of Fapi_UpdateStatusProgram() via CAN, and it returns 0, indicating that there were no errors with the write.

The only memory location that has 0x5A5A5A5A in it after a CAN update on the RM44 board is 0xF0404F44, but I think that's just coincidence. 0xF020F000 still shows 0xFFFFFFFF.

All of the source/include files are shared between the RM44 and RM46 versions of the BootLoader except bl_link.cmd, where the differences are in the RAM/FLASH sizes. I've checked the HALCoGen projects against each other and made sure the RM44 version matched the RM46 version in the Flash section.

The zip file contains the linker command files, renamed to indicate which variant they go with, the bl_link.h header file, and a doc with images showing the correct flash write result for the RM46 and the only memory location containing 0x5A5A5A5A for the RM44.

RM44_v_RM46.zip

Any thoughts on what I could be missing would be greatly appreciated. It's probably some dumb little thing I'm missing in HALCoGen or the project settings to prevent writing to that location.

Thanks!

- Tom

  • 0
    TI__Guru**** 186226 points

    Hi Tom,

    The EEPROM on RM44Lx is different from the EEPROM on RM46Lx. RM44Lx has 16 sectors and each sector is 4KB. RM46Lx has 4 sectors, and each sector is 16KB.

    0xF0404F44 is the ECC value of flash content at 0x4F44*8 = 0x27A20 (flash sector 7).

    Can you share the source code of Fapi_UpdateStatusProgram() in BL?

  • 0 in reply to QJ Wang
    Prodigy 230 points

    I am checking the RM44 project for anywhere ECC might be selected.

    Here is the Fapi_UpdateStatusProgram() source, shared by all the BL variants.

    uint32_t Fapi_UpdateStatusProgram(uint32_t Flash_Start_Address, uint32_t Data_Start_Address, uint32_t Size_In_Bytes)
{
    register uint32_t src = Data_Start_Address;
    register uint32_t dst = Flash_Start_Address;
    unsigned int bytes;

    if (Size_In_Bytes < 16)
        bytes = Size_In_Bytes;
    else
        bytes = 16;

    Fapi_setActiveFlashBank(Fapi_FlashBank7);
    Fapi_enableEepromBankSectors(0xFFFFFFFF,0xFFFFFFFF);

//            Fapi_enableMainBankSectors(0xFFFF);

    Fapi_issueAsyncCommandWithAddress(Fapi_EraseSector, (uint32 *) APP_STATUS_ADDRESS);
    while(Fapi_checkFsmForReady() != Fapi_Status_FsmReady){}

    while( FAPI_CHECK_FSM_READY_BUSY != Fapi_Status_FsmReady );
    while(FAPI_GET_FSM_STATUS != Fapi_Status_Success);
//            Fapi_issueAsyncCommand(Fapi_ClearStatus);
    Fapi_issueProgrammingCommand((uint32_t *)dst,
                                (uint8_t *)src,
                                (uint8_t) bytes,
                                NULL,
                                0,
//                              Fapi_DataOnly);
                                Fapi_AutoEccGeneration);

    while( Fapi_checkFsmForReady() == Fapi_Status_FsmBusy );
    while(FAPI_GET_FSM_STATUS != Fapi_Status_Success);
    while(FLASH_CONTROL_REGISTER->FmStat.FMSTAT_BITS.BUSY == Fapi_Status_FsmBusy);

    // Adding this to detect error in write
    if (FLASH_CONTROL_REGISTER->FmStat.u32Register != 0) {
        return (1);
    }

    return (0);
}

    As always, thanks for the help!

    - Tom

  • 0 in reply to Thomas Green1
    Prodigy 230 points

    I scoured my notes from last year and (re)discovered how I got this working the first time. Thank goodness there was a time when I took good notes.

    "Took another look at it today, and in the debugger noted that the return value of `Fapi_issueProgrammingCommand` was 12, which indicates `Fapi_Error_Async_IncorrectDataBufferLength`. After playing around a bit with the passed-in value for `bytes`, I hard-coded that value to 4, and it worked. I don't know why it worked, but it did" .

    So I again hard-coded `bytes = 4;` and it's back to working correctly. I didn't look, but that likely means the code length, etc is not being written, just the 0x5A5A5A5A. 

    I'd still like to understand why this fix works and if there's a different way to go about it, but for the moment I'm moving on.

    - Tom

  • 0 in reply to Thomas Green1
    TI__Guru**** 186226 points

    Hi Tom,

    ECC is calculated on 64-bit aligned addresses up to the data width of the bank (128-bit for RM44x). Data not supplied is treated as 0xFF. If only 4 bytes of data (0x5A5A5A5A) is provided,  0x5A5A5A5AFFFFFFFF will be written and ECC of this 8-bytes of data will calculated. 

    You can specify the 'bytes' as 4, 8, 2, etc.