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.

CCS/TM4C1230C3PM: Problem dealing with FLASH

Part Number: TM4C1230C3PM
Other Parts Discussed in Thread: UNIFLASH, CC1310

Tool/software: Code Composer Studio

Hello Friends,

In my project i am supposed to write some values  to the internal FLASH memory of the microntroller TM4C1230C3PM) . We actually can read and write to the flash memory, but after REBOOT  i am encountering the problem "CORTEX_M4_0: Can't Run Target CPU: (Error -1268 @ 0x1090001) Device is locked up in Hard Fault or in NMI.  " 

The setting of my memory for the microcontroller is as follows :

/******************************************************************************
 *
 * Default Linker Command file for the Texas Instruments TM4C1230C3PM
 *
 * This is derived from revision 15071 of the TivaWare Library.
 *
 *****************************************************************************/

--retain=g_pfnVectors

MEMORY
{
    FLASH (RX) : origin = 0x00000000, length = 0x00007C00
    SRAM (RWX) : origin = 0x20000000, length = 0x00003000
	FLASHDATA (RWX) : origin = 0x00007C00, length = 0x00000400

}


/* The following command line options are set as part of the CCS project.    */
/* If you are building using the command line, or for some reason want to    */
/* define them here, you can uncomment and modify these lines as needed.     */
/* If you are using CCS for building, it is probably better to make any such */
/* modifications in your CCS project and leave this file alone.              */
/*                                                                           */
/* --heap_size=0                                                             */
/* --stack_size=256                                                          */
/* --library=rtsv7M4_T_le_eabi.lib                                           */

/* Section allocation in memory */

SECTIONS
{
    .intvecs:   > 0x00000000
    .text   :   > FLASH
    .const  :   > SRAM
    .cinit  :   > FLASH
    .pinit  :   > FLASH
    .init_array : > FLASH

    .vtable :   > 0x20000000
    .data   :   > SRAM
    .bss    :   > SRAM
    .sysmem :   > SRAM
    .stack  :   > SRAM
}

__STACK_TOP = __stack + 512;


and the function used in my FW are:

#define FLASHDATA_VERSION  ((uint32_t) 0x00007C00)
#define FLASHDATA_ADC1_CAL ((uint32_t) 0x00007C00 + 4)
#define FLASHDATA_ADC2_CAL ((uint32_t) 0x00007C00 + 8)
#define FLASHDATA_ADC3_CAL ((uint32_t) 0x00007C00 + 12)

uint8_t read_byte[4] = { 0x00, 0x00, 0x00, 0x00 };
uint32_t flashBuffer[5] = { 0, 0, 0, 0, 0 };
            FlashProtectSet(FLASHDATA_VERSION, FlashReadWrite);
            FlashErase(FLASHDATA_VERSION);
            FlashProgram(flashBuffer, FLASHDATA_VERSION, 4);
            FlashProgram(flashBuffer + 1, FLASHDATA_ADC1_CAL, 4);
            FlashProgram(flashBuffer + 2, FLASHDATA_ADC2_CAL, 4);
            FlashProgram(flashBuffer + 3, FLASHDATA_ADC3_CAL, 4);

            for (i = 0; i < 4; i++)
            {
                read_byte[i] = *(uint8_t *) (FLASHDATA_VERSION + (sizeof(uint8_t) * i));
            }
            for (i = 0; i < 4; i++)
            {
                read_byte[i] = *(uint8_t *) (FLASHDATA_ADC1_CAL + (sizeof(uint8_t) * i));
            }
            for (i = 0; i < 4; i++)
            {
                read_byte[i] = *(uint8_t *) (FLASHDATA_ADC2_CAL + (sizeof(uint8_t) * i));
            }
            for (i = 0; i < 4; i++)
            {
                read_byte[i] = *(uint8_t *) (FLASHDATA_ADC3_CAL + (sizeof(uint8_t) * i));
            }

            FlashProtectSet(FLASHDATA_VERSION, FlashReadWrite);

Note: I am actually reading the values written to the flash Memory correctly when i check them in the Debugger.

Thank you in advance for your valuable feedback.

with regards,

Marco.

  • Hello Marco,
    This issue has popped up from time to time on this forum. There are several threads here that discuss it. A search should yield some results.

    Here are some results you may want to take a look at:
    e2e.ti.com/.../749460
    e2e.ti.com/.../687574

    Thanks
    ki
  • Hello Ki-Soo Lee,

    thanks for the quick answer but I just read different posts with different problems with UniFlash.. Mine is for sure an error due to wrong addressing when i Write data flash.

    What I've done is declearing a new "user-custom session" in my linker script and resized the section called FLASH. But for sure I'm missing some steps in the code because it seems to be like a CRC error of the flash. This error occours only when I reboot the board. [If I write in flash and I don't reboot the board the FW works fine]

    Looking at the data-sheet I can't see the addressing of the flash, so I'm not able to suppose nothing. As soon as I can, I'll try to enable the ARM Advanced Features in order to give you further information..

    Any idea?

    Thanks,

    Marco.

  • Hi Marco,
    I will bring this thread to the attention of the device experts. They should be able to provide some more suggestions.

    Thanks
    ki
  • Hi Ki-Soo Lee,

    Could I mantain this thread open and wait for a reply from experts in this thread?

    Thanks,

    Marco.

  • Yes. I moved it into the device forum and have it flagged to the appropriate group.
  • You cannot erase or program the main flash memory while you are executing code from the flash. Have you considered using the emulated EEPROM instead?
  • That is not entirely true. I have a program on the TM4C129C that successfully changes data in the flash while running from flash. You just want to make sure that you are not running from the same flash page that you are erasing. You'll want to double check the flash page size for this processor, but I think it's 1KiB in size on the TM4C123, and 16KiB on the TM4C129.

    Either way, I know that some processors like to store "User Registers" or "User Settings" in the last page of flash. The CC1310 does this for sure.
    Perhaps you should try moving the data one page closer to the beginning. If that solves it, then you are most likely erasing important settings.
  • OK, to be precise, the instruction or literal fetches are stalled when programming or erasing the same flash bank that you are executing from. It can be done, but you have to tolerate the stall which is usually a bad thing in a real time control system. The TM4C129 family has two bank pairs (4 banks) and you can program/erase the upper bank pair while executing from the lower pair without stalling. The TM4C123 family only has one bank pair.

    To Marco, the original poster, if the amount of data you need in non-volatile memory is what you have in the example, using the emulated EEPROM is the best choice.
  • When the CPU is stalled with a flash access to a bank that is being programmed or erased, the debugger cannot connect to the device. If the code you have shown above loops constantly erasing and reprogramming, that could be the issue you have connecting after a reboot.
  • Hi guys,

    thanks to all for all the replies.

    Finally, I almost solved my problem using EEPROM instead of flash memory.

    In my opinion the issue was generated by the linker file, infact replacing the linker file with the original one, the board reboots sucessfully. [changed the line from .const > SRAM to const > FLASH]. Maybe the "write on flash" approach was still working :D

    By the way, I'm still not understanding different things I'd like to understand :D :

    1) why  says "emulated" EEPROM?. Looking at the data-sheet of the component seems to be real EEPROM.

    2) Bob Crosby, what is your solution if I want to make a bootloader? I thinked that I can split flash into 2 parts (1 for bootloader and 1 for application). From bootloader region I write to application's region and finally I jump to application, but as you said this can't be the best solution.. How do you deal with that?

    Sorry if I'm going OT but I'd also like do understand this thinks :D .. the original problem is solved !!

    Thanks,

    Marco.

  • Marco Semenzato said:
    1) why  says "emulated" EEPROM?. Looking at the data-sheet of the component seems to be real EEPROM.

    Page 458 of the datasheet describes the EEPROM as "The EEPROM operates using a traditional Flash bank model which implements EEPROM-type cells, but uses sector erase." It is truly flash memory that is separate from the main flash and an internal state-machine does all of the work to make it behave like EEPROM. In true EEPROM individual bits can be programmed or erased. This memory uses sector erase but the state-machine hides the difference except that a "behind the scenes sector erase" causes the write time to be longer sometimes.

    Marco Semenzato said:
    2) Bob Crosby, what is your solution if I want to make a bootloader? I thinked that I can split flash into 2 parts (1 for bootloader and 1 for application). From bootloader region I write to application's region and finally I jump to application, but as you said this can't be the best solution.. How do you deal with that?

    There are two good options. One is to use the built-in ROM based bootloader. It can reprogram the flash because it operates from ROM and not from the flash. If the ROM based bootloader does not meet your needs, you can modify the flash based bootloader provided by TI. The flash based bootloaders copy code into RAM and then jump to the RAM to execute the erase and reprogramming. Here is a document about TM4C bootloaders:

    www.ti.com/.../spmu301d.pdf

  • You are right, the ".const" section needs to be in Flash, not SRAM. Sorry I did not catch that earlier.
  • Hi Bob Crosby,

    thanks a lot for all your time, clear replies and for the document you provided me.

    Now I can say that my problem is solved :D .

    Thanks and best regards,

    Marco