• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 495 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

RTOS/TM4C1290NCPDT: TIVA C Flash programming gets aborted

paddu2017
Expert 2885 points
Part Number: TM4C1290NCPDT

Tool/software: TI-RTOS

Hi,

We are getting abort error when programming a part for the TIVA C memory.

TI-RTOS Version:2.16.01.14

Our application has 2 blocks of memory for use data(16KB each),
We are able to program 1st block of the memory(0x000200000) without any problem,
but with the 2nd block(0x00024000),the programming gets aborted.

Just for the testing we implement the FlashErase() into the main program
and tried to step execute inside FlashErase() and the program gets aborted in the below code.


// Erase the block.
//
HWREG(FLASH_FMA) = ui32Address;
HWREG(FLASH_FMC) = FLASH_FMC_WRKEY | FLASH_FMC_ERASE;

//
// Wait until the block has been erased.
//
while(HWREG(FLASH_FMC) & FLASH_FMC_ERASE)
{
}

****gets aborted here*****

//
// Return an error if an access violation or erase error occurred.
//
if(HWREG(FLASH_FCRIS) & (FLASH_FCRIS_ARIS | FLASH_FCRIS_VOLTRIS |
FLASH_FCRIS_ERRIS))
{
return(-1);
}

Please let me know if there is any suggestion to troubleshoot this issue.

Best Regards
Paddu

  • 0
    TI__Guru*** 135355 points
    Hello Paddu,

    What error specifically occurs when the 'abort' happens? Can you post the details from the error? That could be telling for what is going on.

    Are those banks of memory reserved for data storage via the linker file? Can you post the linker file on E2E so I can review it? It would be the .cmd file for your project.

    Also just for clarity, you mention locations of 0x000200000 and then 0x00024000, I am sure you meant that the first location is actually 0x00020000 right? I hope so as we don't have a device that's 2MB in the TM4C portfolio!
  • 0 in reply to Ralph Jacobi
    Expert 2885 points
    Hello Ralph Jacobi,

    Thank you for the quick information.
    As per your suggestion there might be something wrong in the
    linker file, we are testing that now.Will come back with the details later.

    Best Regards
    paddu
  • 0 in reply to paddu2017
    Expert 2885 points

    Hi Ralph Jacobi,

    With regards to the abort issue,we came to know this error
    occured because of the memory partition in CMD file.

    Below is the brief detail of this application and the issue.

    In this customer application the TI-RTOS(system) and Application(APP) are mapped into seperate memory,
    and whenever there is an update only the application part is updated through Bootloader.
    this was also disscussed in the E2E here.

    To implement this,the main memory is divided into two group as show below.
    The system section is always fixed whereas the APP section is updated frequently.

    MEMORY
    {
    /*
    FLASH (RX) : origin = 0x00000000, length = 0x00080000
    SRAM (RWX) : origin = 0x20000000, length = 0x00040000
    */

    SYSTEM_FLASH (RX) : origin = 0x00000000, length = 0x00020000
    APP_FLASH (RX) : origin = 0x00020000, length = 0x00080000
    SYSTEM_SRAM (RWX) : origin = 0x20000000, length = 0x00020000
    APP_SRAM (RWX) : origin = 0x20020000, length = 0x00020000
    }


    Out of all the sections, we have below two sections which is causing this
    abort when programming.

    ・cinit ​​(initialization table)
    ・EK_TM4C129EXL.obj(.const) ( device related intialization )

    If we map this section to App, we get abort error while updating the APP(application).
    But if we map this to System, the program won't run properly after update
    because the APP(Application) data seems to be included in the ".cinit".

    Please let me know if there is any suggestion to map ".cinit" properly
    is it possible to re-map the data inside ".cinit" to a seperate memory?

    Best Regards
    paddu

  • 0 in reply to paddu2017
    TI__Guru*** 135355 points

    Hello paddu,

    It looks like it is possible to re-map .cinit into a separate memory location, but not with the method you described. Please see this E2E post for details on what steps to take: https://e2e.ti.com/support/development_tools/compiler/f/343/p/220978/780173#780173 (note you may need to edit the .cfg file in a text editor)