TM4C1297NCZAD: Recover bootloader

Hi Suzanne,

  Let me try to understand your setup first.

  - I suppose you have a custom board with TM4C1297NCZAD MCU, correct? 

  - You have an external XDS110 debug probe, correct? Perhaps you can take a picture of the XDS110 you are using.

  - What bootloader are you talking about? A flash bootloader is normally loaded to 0x0. Neither 0x2800 nor 0x1800. This is what I'm confused with. Are you talking about your application firmware to be loaded at 0x2800, Can you please clarify?

  - Another thing I'm confused with is how can you use LM flash programmer. The LM flash programmer is meant to be used for the LaunchPad which has an on-board ICDI debug probe. The LM flash programmer does not support XDS200, XDS100 and other debug probe like JLink. I don't think it supports XDS110 either even though XDS110 was based on ICDI. Did you successfully use LM flash programmer to program your device in the past with XDS110 because this is combination is new to me. Normally, you will use Uniflash which is another standalone flash programmer tool that supports a variety of debug probes. 

HI Charles,

Yes, it is a custom board. This is the XDS110 debugger that i am using https://www.ti.com/tool/TMDSEMU110-U?keyMatch=XDS110

I am following the guide given by https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1031501/tm4c1297nczad-bootloader-code/3814744?tisearch=e2e-sitesearch&keymatch=%25252520user%2525253A174606#3814744

I am following the guide SPMU373 to use the LM flash programmer to flash the bootloader. The base code that I used is ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c1294xl\boot_serial. 

With LM Flash Programmer, I am using USB DFU to flash it via the USB connection. I have successfully flash it and works when I use the correct address which is 0x2800.  However, after I flashed it with 0x1800, I am unable to detect it anymore. I also have XDS110 and XDS200 JTAG programmer. Both programmer are unable to detect the board. 

How can I recover it and get the board booting again to application? 

Thanks

Hi Suzanne,

   I have some comments.

  - The stock example ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c1294xl\boot_serial is a flash based bootloader for bootloading from a UART port. Did you modify the bl_config.h file in the project to bootload from the USB port instead?

  - Assume you modified boot_serial so that you can bootload from a USB port, this is still a bootloader. This flash based bootloader must start at 0x0. Not 0x2800 or 0x1800.

  - For TM4C129 devices, the application should start at 0x4000, not 0x2800. The 0x2800 you see in the TivaWare user's guide is for TM4C123. TM4C123 has a different flash architecture in terms of flash sector organization compared to TM4C129. If you look at the bl_config.h file for the ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c1294xl\boot_serial\bl_config.h, it has the below #define.

//*****************************************************************************
//
// 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 0x4000

 - Just to clarify again, there are two pieces of software for bootloading. First is a bootloader and another is your application firmware. The bootloader must start 0x0 and your application firmware can start at 0x4000 or higher (multiple of 1024 bytes aligned to a flash page boundary). If you look at the TivaWare examples, the boot_serial is a bootloader. The boot_demo1 or boot_demo2 is a application firmware example to be loaded through the UART port. 

  - While the flash is completely erased and if you want to use the "ROM based" bootloader to first load your "flash based" boot_serial then you need to specify the LM flash programmer offset address to 0x0. Once the boot_serial is loaded, the processor will run from 0x0. This boot_serial will then load your application firmware from 0x4000 via UART or USB port depending if you have modified boot_serial to use the USB port. In this case, the LM flash programmer offset address will need to be 0x4000. Again, not 0x1800 or 0x2800. The 0x2800 is for TM4C123 MCU, not TM4C129 MCU. 

  - Please erase the flash first and do the steps I mentioned above.  

HI Charles,

I am able to revive the board with your advice.

Additional question:

I am building my code and the output is DLPNIRSCAN.bin. Is this just application or both bootloader and application? I tried flashing this at 0x4000 and it does not work. I check the bin and this binary starts at 0x0. I am trying to do firmware update for the application part. How can i generate the correct bin to do this? Initially I thought that using the bin from compile will work. It does not seems to be the case. 

Suzanne Lim said:

I am building my code and the output is DLPNIRSCAN.bin. Is this just application or both bootloader and application?

This DLPNIRSCAN.bin must be your own application. I think you should know better than me on how it was created. When you build this application, you must make sure it is linked to 0x4000. See the boot_demo1_ccs.cmd linker command file on how the example application is built. Below is the snippet of the .cmd file. 

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

The boot_serial or any bootloader you build should start at 0x0. You can load this bootloader through JTAG by CCS or LM flash programmer. Once the bootloader is running it will program your application (e.g. DLPNIRSCAN.bin) to address 0x4000. But you must compile and link your application firmware DLPNIRSCAN.bin to 0x4000 first. If you compile your application to start 0x0 and have the bootloader to program the application at 0x4000, it will not work. 

  I strongly suggest you start with the TivaWare bootloader examples and get a feel for it. Simply load the boot_serial (this is a bootloader) at 0x0 through JTAG. Once it is running, you can specify boot_demo1.bin as the application to be loaded in LM flash programmer with offset address at 0x4000. Look at how boot_demo1 example on how it is built. Again, the stock TivaWare example boot_serial as is will bootload from the UART port. You just need to modify the bl_config.h to select for bootloading from the USB port. 

Suzanne Lim said:

I am building my code and the output is DLPNIRSCAN.bin.

Is this for DLPNIRNANOEVM or any other TI DLP EVM / reference design?

HI Charles,

The .cmd file for my project is as following

--retain=g_pfnVectors

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

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

}

/* 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:   > APP_BASE
    .text   :   > FLASH
    .const  :   > FLASH
    .cinit  :   > FLASH
    .pinit  :   > FLASH
    .init_array : > FLASH
    *		:   > FLASH

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

__STACK_TOP = __stack + 512;

Is it possible to not have a flash bootloader and directly runs the application? If I understand this correctly, in my case, the ROM bootloader directly runs the application from 0x0. If I need to do update from USB with the flash bootloader, I need to modify my .cmd file. 

Yes, I have modify the bl_config.h to support both UART and USB. My concept is to have an external WIFI chip to flash the TIVA chip via UART and still have USB available for external flashing. 

HI Chester,

This was derived from the reference design. 

HI Charles, 

I changed 

FLASH (RX) : origin = APP_BASE, length = 0x00100000

to 

FLASH (RX) : origin = APP_BASE, length = 0x000fc000

with 

#define APP_BASE 0x00004000

I am currently getting this error

"configPkg/linker.cmd", line 141: warning #10096-D: specified address lies outside memory map
error #10264: DEFAULT memory range overlaps existing memory range FLASH
error #10264: DEFAULT memory range overlaps existing memory range SRAM
error #10264: DEFAULT memory range overlaps existing memory range SDRAM
error #10010: errors encountered during linking; "DLPNIRSCAN.out" not built

Where should I look?

Hi Suzanne,

Suzanne Lim said:

Is it possible to not have a flash bootloader and directly runs the application? If I understand this correctly, in my case, the ROM bootloader directly runs the application from 0x0.

It is fine to not have a flash bootloader at 0x0. You can have your application start at 0x0. Most of the customer applications do not have bootloader. You can load your application through JTAG by CCS or LM flash programmer or Uniflash. Pretty much all the TivaWare examples do not require bootloader. Just look at the blinky.bin example. How would you load and run the blinky program? Your application is no different. You can also load your application by using the ROM based bootloader through UART. The ROM bootloader will only bootload from the UART port if the flash is empty (in erased state). ROM bootloader look at the first two words in flash memory which contain the stack pointer and reset vector. If these two words are non-FFFFFFFF then it thinks there is application at 0x0 and will run the application. If the two words are 0xFFFFFFFF then the ROM bootloader will search the ports among UART0, SSI0, I2C2, CAN, USB and Ethernet to load your firmware.

You title started with how to recover the bootloader and this leads me to think you are using a flash based bootloader.

HI Charles, 

I changed 

FLASH (RX) : origin = APP_BASE, length = 0x00100000

to 

FLASH (RX) : origin = APP_BASE, length = 0x000fc000

with 

#define APP_BASE 0x00004000

I am currently getting this error

"configPkg/linker.cmd", line 141: warning #10096-D: specified address lies outside memory map
error #10264: DEFAULT memory range overlaps existing memory range FLASH
error #10264: DEFAULT memory range overlaps existing memory range SRAM
error #10264: DEFAULT memory range overlaps existing memory range SDRAM
error #10010: errors encountered during linking; "DLPNIRSCAN.out" not built

Where should I look?