TM4C129XNCZAD: Why LM Flash doesn't Provide address offset while flashing through Ethernet

Hi Charles,

Thank you for your response. 

I understood what you said. My concern is different, suppose I have flash bootloader starting at 0x00 and my application is starting at 0x4000. I want to write only application (starting from 0x4000), in other words I have only one binary file which has application code and I want to write it at 0x4000 address from LM Flash using EMAC. How can I do that ? According to you I will have to combine bootloader code and application code and make one binary and flash it at 0x00 through LM Flash using EMAC isnt it ? Normally bootloader is not updated again and again but application is being updated multiple times to fix anomalies or enhance features etc.

According to this logic even serial (UART) shall not option for offset address. Just write everything at 0x00 isnt it ? I

Parvez Akhtar Shaikh said:

My concern is different, suppose I have flash bootloader starting at 0x00 and my application is starting at 0x4000. I want to write only application (starting from 0x4000), in other words I have only one binary file which has application code and I want to write it at 0x4000 address from LM Flash using EMAC. How can I do that ?

Hi,

  I will suggest you try out the boot_emac_flash (this is a bootloader starting at 0x0) and boot_demo_emac_flash (this is an application starting 0x4000). Once you run these two examples you will have a better picture of how the bootloader works. 

  In boot_emac_flash project you will find the bl_config.h file in the project. See below snippet where the application is defined to start at 0x4000. This is how the bootloader know to program the application firmware at 0x4000. 

//*****************************************************************************
//
// The starting address of the application.  This must be a multiple of 1024
// bytes (making it aligned to a page boundary).  A vector table is expected at
// this location, and the perceived validity of the vector table (stack located
// in SRAM, reset vector located in flash) is used as an indication of the
// validity of the application image.
//
// The flash image of the boot loader must not be larger than this value.
//
// Depends on: None
// Exclusive of: None
// Requires: None
//
//*****************************************************************************
#define APP_START_ADDRESS       0x00004000

//*****************************************************************************
//
// The address at which the application locates its exception vector table.
// This must be a multiple of 1024 bytes (making it aligned to a page
// boundary).  Typically, an application will start with its vector table and
// this value should be set to APP_START_ADDRESS.  This option is provided to
// cater for applications which run from external memory which may not be
// accessible by the NVIC (the vector table offset register is only 30 bits
// long).
//
// Depends on: None
// Exclusive of: None
// Requires: None
//
//*****************************************************************************
#define VTABLE_START_ADDRESS    0x00004000

//*****************************************************************************
//
// The size of a single, erasable page in the flash.  This must be a power
// of 2.
//
// Depends on: None
// Exclusive of: None
// Requires: None
//
//*****************************************************************************
#define FLASH_PAGE_SIZE         0x4000

Next look at boot_demo_emac_flash_ccs.cmd file in the boot_demo_emac_flash project. See the below snippet of the linker command file where the application is relocated to 0x4000. 

/* The starting address of the application.  Normally the interrupt vectors  */
/* must be located at the beginning of the application.                      */
#define APP_BASE 0x00004000
#define RAM_BASE 0x20000000

/* System memory map */

MEMORY
{
    /* Application stored in and executes from internal flash */
    FLASH (RX) : origin = APP_BASE, length = 0x000fc000
    /* Application uses internal RAM for data */
    SRAM (RWX) : origin = 0x20000000, length = 0x00040000
}

When the flash-base bootloader (the boot_emac_flash) starts running, it will program the application (boot_demo_emac_flash) to 0x4000. You do not use the LM flash programmer to specify address offset for the application to be programmed. 

Yes this is possible with serial only I never asked you about serial. But this is not possible with ethernet. Why offset address is disabled in ethernet ? This is the question I am asking.

Ok, I seem to be able to see your observation. Below is what I did. 

- I first modified the linker command file for C:\ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c1294xboot_demo_emac_rom to link the APP_START to 0x4000. 

- I then load the boot_emac_flash (flash bootloader) to 0x0 using JTAG. 

- I let the flash bootloader to program the application in conjunction with LM flash programmer to transfer application image using Ethernet port. 

- The boot_emac_flash will correctly program the application at 0x4000 as we can specify where the application will be programmed to using the bl_config.h file. 

- Once the boot_demo_emac_rom is running, it will call ROM_UpdateEMAC() and transfer the control to the ROM bootloader. 

- The ROM bootloader fails to program boot_demo_emac_rom at 0x4000 but rather at 0x0. 

I don't know why ROM EMAC bootloader will only program any image at 0x0. ROM is not something that can be altered after the silicon is released. I will suggest you use the flash bootloader instead. As I mentioned before, even if you can successfully use the ROM bootloader to program the application at 0x4000 but you will have a empty space between 0x0 and 0x3FFF. It will not work anyway as the processor must see a valid stack pointer and reset vector at 0x0 and 0x4. If you are going to have a program like a flash bootloader sitting at 0x0, you might as well just use the flash-based bootloader to program your application instead of using ROM bootloader. 

Finally, You understood my problem but could not offer a solution. Anyway, we finally found a bug and I hope it can be resolved in next silicon release. Thank you.