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.

Facing an issue while testing the copy flash image from one flash memory to other

Other Parts Discussed in Thread: TM4C129DNCPDT

Hi,

In my work, i am writing my two application's binary images at two different memory locations in the flash memory. One of the binary resides in the upper half of the flash and other one in lower half. Both the binaries are programmed to blink a different colored LED continuously. Now i am copying the binary from upper half of the flash memory to other(lower half of the flash memory) and jumping to the bootsection of lower half of the flash memory and i can see that the copied image runs successfully. Now i wanted to make sure that even if i now erase the image present in the upper half of the flash memory(which is already copied in the lower half), it should not create any impact on execution of the binary present at lower half. But, that's not happening. When i copy the flash image present in upper half of the flash to lower half addres of the flash memory, and then erase the binary present in the upper half, and then jump to the boot section of the lower image meomory, it ends up in a hard fault. I am not  getting why?

I am using Tiva series TM4C129DNCPDT as a controller on my board with XDS200 usb emulator.

Here are the details of what i am actually doing:

1) I have a blinky application which blinks red colored LED on my board continuously. It is flashed at address 0x84000 on the flash memory. Please find the attached linker command file for it in the text format above.

2) Then i have my bootloader binary(5KB in size) copied at address 0x80000 on the flash memory

3) Then i  have  a binky application which blinks green colored LED on my board continuously. It is flashed at address 0x4000 on the flash memory. Please find the attached linker command file for it in the text format above.

4) Then start debugging the bootloader code (who's binary is also present in the star addres of the upper half of the flash), which starts at address 0x00.

Here is a snapshot of what my  boot loader code is doing:

int main(void)

{

set_up_modules();

/* Test copy_flash_image functionality */

copy_flash_image(0x4000, 0x84000, 9216);

erase_bad_image_flash_memory(0x84000, 9216);

__asm(" mov R0, #0x8000");

__asm(" mov PC, r0\n"

" bx r0\n"); }

I can see that the memory location 0x4000 onwards are getting erased and written by the data present at memory location 0x84000, but after that when i erase the memory contents of 0x84000, and then jumps to the boot section of the lower half of memory, it ends up in a segmentation fault.

I am not able to reason it out like why it is happening and need some expert's help on this.

Please have a look and help me on this.

Thanks in advance.

Regards,

Shrikant

#define APP_BASE 0x00084000
#define RAM_BASE 0x20000000

--retain=g_pfnVectors

MEMORY
{
    FLASH (RX) : origin = APP_BASE, length = 0x00100000
    SRAM (RWX) : origin = 0x20000000, length = 0x00040000
}

/* 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
{

	boot_section > 0x88000
    {
       -l rtsv7M4_T_le_v4SPD16_eabi.lib<boot.obj>(.text)
    }

    .intvecs:   > APP_BASE
    .text   :   > FLASH
    .const  :   > FLASH
    .cinit  :   > FLASH
    .pinit  :   > FLASH
    .init_array : > FLASH

    .vtable :   > RAM_BASE
    .data   :   > SRAM
    .bss    :   > SRAM
    .sysmem :   > SRAM
    .stack  :   > SRAM
}

__STACK_TOP = __stack + 512;
#define APP_BASE 0x00004000
#define RAM_BASE 0x20000000


--retain=g_pfnVectors

MEMORY
{
    FLASH (RX) : origin = APP_BASE, length = 0x00100000
    SRAM (RWX) : origin = 0x20000000, length = 0x00040000
}

/* 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
{
	boot_section > 0x8000
    {
       -l rtsv7M4_T_le_v4SPD16_eabi.lib<boot.obj>(.text)
    }


    .intvecs:   > APP_BASE
    .text   :   > FLASH
    .const  :   > FLASH
    .cinit  :   > FLASH
    .pinit  :   > FLASH
    .init_array : > FLASH

    .vtable :   > RAM_BASE
    .data   :   > SRAM
    .bss    :   > SRAM
    .sysmem :   > SRAM
    .stack  :   > SRAM
}

__STACK_TOP = __stack + 512;

 

  • Hello Shrikant

    When you do the erase operation are you still running the code in the 0x80000 region?

    Regards

    Amit

  • Hi,

    I think the behaviour related is expected, since you use the absolute linker default option, which is usual, as opposed to PIC option (Position Independent Code). AFAIK it is supported for Tiva, while for other TI micros is not.

    But if the applications run OK in its default location why to run it again after copy? shouldn't be wise to perform a checksum instead, to confirm it was copied flawlessly? 

    Petrei

  • Hi Amit,

    As you can see in the bootloader code, when i erase the code at location 0x84000, it has alreday been copied to memory loction 0x4000. After that i jump to the adress 0x8000(where boot section is present and it should excute the copied binary sucessfully

  • Hello Shrikant

    Shouldn't the jump location be 0x4000 where the copied application binary is kept? Secondly do note that the Vector Table may still pointing to 0x84000 region, so an interrupt will be wrongly branched.

    Regards

    Amit

  • Hi Amit,

    Actually you are right. We were also previously trying to do the same thing and jump to 0x4000, but as in one of my previous post i have reported that the actual application code was starting with an offset of 0x338 and this offset varies from application to application. So we had a solution to avoid this problem in which we can define our boot section in the linker comand file. When we jump to the address location where boot section is kept, it then jumps correctly to whatever is the start of the application address, we need not to bother about it. So the linker command files i have attached for both my blinky application contains boot sections defined at different addresses.

    I am not aware about how the vector table will play role here. Can you please explain it?

  • Hello Shrikant,

    The function of the boot loader is to get in the new application which is full executable. One of the aspect is to ensure that just like the boot loader is at 0x0, the Application is always starting at a fixed location, and if it were to be changed to 0x0 then the application can run by itself.

    The vector table is at the location 0xE000ED08. The vector table contains the start address the CPU has to use to find the branch code for the corresponding interrupt vector. if it is not programmed it defaults to 0x0 which would be the boot loader's vector table and not the application's vector table.

    Regards

    Amit