• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 247 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.

TM4C129ENCPDT: The starting address of the flash memory will change and the software will no longer work.

Muneto Maeda
Prodigy 160 points

Part Number: TM4C129ENCPDT

Tool/software:

While debugging a product using Tm4C129ENCPDT, my code stopped working completely.

I checked the flash contents and found that the start address was set to 0x4000, but was changed to 0x84000.

This is difficult to reproduce and only happens occasionally. What do you think is causing this?

Or is there some behavior in the CPU where anything written to the start address 0x4000 is moved to the 0x84000 area as a function of the CPU?

Normally, you would write the bootloader and backup program to the area after 0x4000, and write your normal program to the area after 0x80000. Then, at boot time, use mirror mode to execute the program from the area after 0x80000.

  • 0
    TI__Guru**** 191886 points

    Hi,

    Muneto Maeda said:

    This is difficult to reproduce and only happens occasionally. What do you think is causing this?

    Aer you saying that most of the time the code works fine?

    Muneto Maeda said:

    Or is there some behavior in the CPU where anything written to the start address 0x4000 is moved to the 0x84000 area as a function of the CPU?

    Normally, you would write the bootloader and backup program to the area after 0x4000, and write your normal program to the area after 0x80000. Then, at boot time, use mirror mode to execute the program from the area after 0x80000.

    The bootloader will reside at 0x0. After reset, it will check for valid stack pointer and reset vector at addresses 0x0 and 0x4. If they are valid, then the processor will jump to the application. If your normal application is at 0x80000 then it is supposed to jump to 0x80000 because the reset vector at 0x4 will point to your normal application. There is no reason for the processor to jump to 0x4000 to run your backup firmware unless the reset vector says so or your normal application or your custom bootloader is asked to to jump to the backup application under circumstances you design to. 

    You might also want to check what you have written to NVIC_VTABLE register. 

    On system reset, the vector table is fixed at address 0x0000.0000. Privileged software can write to
    the Vector Table Offset (VTABLE) register to relocate the vector table start address to a different
    memory location, in the range 0x0000.0400 to 0x3FFF.FC00 (see “Vector Table” on page 119). Note
    that when configuring the VTABLE register, the offset must be aligned on a 1024-byte boundary.

  • 0 in reply to Charles Tsai
    Prodigy 160 points

    It was incorrect to say that the boot loader is placed at 0x4000.
    The boot loader is correctly placed at 0x0, the backup program at 0x4000, and the normal program at 0x84000. The offset of the vector table is set to 0x4000, and after the backup program is started first, the program in 0x84000 is used using the mirroring function.However, the problem that occurred with this CPU is that the software suddenly stopped booting and all the 0x0~0x84000 bootloader + backup program areas were deleted.
    This does not occur every time the power is turned on, but rarely, making it difficult to reproduce and resolve the problem.
    I would like to know what is causing this problem.
    Or is there a CPU function that deletes all areas from 0x0 to 0x80000 at once?

  • 0 in reply to Muneto Maeda
    TI__Guru**** 191886 points
    Muneto Maeda said:
    It was incorrect to say that the boot loader is placed at 0x4000.

    When did I say the bootloader starts at 04000? I always say the bootloader starts at 0x0. 

    Muneto Maeda said:
    the backup program at 0x4000, and the normal program at 0x84000.

    Go back to your original post and I quote "Normally, you would write the bootloader and backup program to the area after 0x4000, and write your normal program to the area after 0x80000. Then, at boot time, use mirror mode to execute the program from the area after 0x80000."  It was you who said the normal program starts from area after 0x80000. Now you said the normal program starts at 0x84000. It is very confusing. Ho 

    Muneto Maeda said:
    after the backup program is started first, the program in 0x84000 is used using the mirroring function

    How does the mirroring function work? Exactly, how do you jump to 0x84000 from 0x4000?

    Muneto Maeda said:
    However, the problem that occurred with this CPU is that the software suddenly stopped booting and all the 0x0~0x84000 bootloader + backup program areas were deleted.

    What do you mean by deleted? If you use the debugger to view the memory from 0x0-0x84000, what do you see? You said the area was deleted. Do you see all F's as if the flash is erased or some random values?

    Muneto Maeda said:
    This does not occur every time the power is turned on, but rarely, making it difficult to reproduce and resolve the problem.

    Do you mean after power up, the flash memory is restored to the correct content from the previous session where you observed the flash was somehow deleted?