TM4C1294NCPDT: Burn new TIVA application Via Ethernet

I will check it, Thank you!

So, in my microcontroller there is a ROM bootloader that handle this, right? I don’t need to program it myself? Only to write the application?

correct. 

Hi Charles,

we discovered that we need to find a solution that does not include the LM Flash programmer tool. Do you know how I can do that?

Thank you

Hi Tzipi,

  If you need to create your own serial programmer, please refer to the below app note. 

https://www.ti.com/lit/pdf/spma074

  Also refer to the bootloader user's guide. 

https://www.ti.com/lit/pdf/spmu301

I need to create my one ETH programmer, not Serial... Do you have any suggestions, documentation or examples for that? 

Thank you

Hi Tzipi,

  Yes, the source code for such a tool called eflash can be found at C:\ti\TivaWare_C_Series-2.2.0.295\tools\eflash. The eflash.exe is in C:\ti\TivaWare_C_Series-2.2.0.295\tools\bin. 

Hi Charles,

I have another question about this example. I want to merge it into my application, and for my understanding, I need to enable the LWIP_UDP flag under lwipopts.h to ensure that the magic packets can be received through UDP port 9.  

I'm using LWIP_TCP for my application. Enabling both can cause me problems?

Thanks,

Tzipi

Hi Tzipi,

  If you want to use both TCP and UDP then you need to enable LWIP_TCP and LWIP_UDP. Refer to the opt.h file. These two #define are optionally defined at the application level using lwipopts.h file. If they are not defined in the lwipopts.h file, then they are both set to 1 in the opt.h file. This means setting both to 1 will not create a problem. 

Hi Charles, 

Thank you for all your help! I was able to merge the example into my code and program my TIVA through the LM FLASH PROGRAM for now. 

The next step is to use eflash code to build my own tool for that.

But I have another problem: Is there a way to recover from an unsuccessful program? If the communication falls in the middle of the burn and the flash doesn't have a valid application, I have to use the JTAG again to program a valid application. There is some way to avoid that?

There is any solution that doesn't involved JTAG to solve this?

Thank you!

Tzipi Kluska said:

But I have another problem: Is there a way to recover from an unsuccessful program? If the communication falls in the middle of the burn and the flash doesn't have a valid application, I have to use the JTAG again to program a valid application. There is some way to avoid that?

Hi,

  Please refer to the booloader user's guide for details about using CHECK_CRC. You can enable CRC checking so that if the application programming/update via Ethernet fails in the middle, the bootloader will try to reload the program again. 

//*****************************************************************************
//
// Enables runtime and download CRC32 checking of the main firmware image.
// If this is defined, the boot loader will scan the main firmware image for
// an image information header (stored immediately above the vector table and
// marked by the words 0xFF01FF02 and 0xFF03FF04). If the header is found and
// the CRC32 value it contains matches that calculated for the image, the
// firmware is run. If the CRC32 does not match or the image information
// is not found, the boot loader retains control and waits for a new download.
// To aid debugging, if this option is used without ENFORCE_CRC being set, the
// image will also be booted if the header is present but the length field is
// set to 0xFFFFFFFF, typically indicating that the firmware file has not been
// run through the post-processing tool which inserts the length and CRC values.
//
// Note that firmware images intended for use with CRC checking must have been
// built with an 8 word image header appended to the top of the vector table
// and the binary must have been processed by a tool such as tools/binpack.exe
// to ensure that the required length (3rd word) and CRC32 (4th word) fields
// are populated in the header.
//
// Depends on: ENFORCE_CRC
// Exclusive of: None
// Requires: None
//
//*****************************************************************************
//#define CHECK_CRC

//*****************************************************************************
//
// This definition may be used alongside CHECK_CRC to remove the debug behavior
// which will allow an image with an uninitialized header to be run. With
// ENFORCE_CRC defined firmware images will only be booted if they contain a
// valid image information header and if the embedded CRC32 in that header
// matches the calculated value.
//
// Depends on: None
// Exclusive of: None
// Requires: CHECK_CRC
//
//*****************************************************************************
//#define ENFORCE_CRC

In the doc it says: 

"If the header is absent or the calculated CRC does not match the expected value, the boot loader retains control and waits for a new firmware image to be downloaded."

The ROM bootloader can get new image via ethernet with the LM FLASH at this point? It doesn't need the application to get the magic word packet?

How it knows the IP address?

Also, the defines "CHECK_CRC" & "ENFORCE_CRC" are under "bl_config.h" file. This file is relevant for the ROM bootloader? I thought it is just for the FLASH bootloader.

I didn't understand how the ROM bootloader gets the new image without the application gets the program command from the LM FLASH and transfer it to the bootloader..

Thanks for your help!

Hi,

  The CHECK_CRC is only available for flash-based bootloader, not ROM bootloader. I will suggest you consider flash-base bootloader for robustness. If you lose power in the middle of Ethernet programming then the firmware may have been partially programmed. There could be valid stack pointer and reset vector at 0x0 and 0x4 already. In this case, the ROM bootloader will assume there is a valid application at 0x0 although it is only partially programmed. The only way for the ROM bootloader to restart the firmware update is to specify a GPIO pin the BOOTCFG register or completely erase the flash so that 0x0 and 0x4 become 0xFFFFFFFF again. Refer to the Bootloader User's Guide for details. 

2 ROM Boot Loader
The ROM boot loader runs from on-chip ROM memory and can be invoked three ways:

1. The ROM boot loader runs and checks for the presence of a valid application by reading the data
at 0x0000.0004. If the data at this address is 0xFFFF.FFFF, the ROM boot loader is mapped
to address 0x0000.0000 and continues to execute. If the data at that address is any other value,
then the application starts instead.

2. The BOOTCFG register specifies a GPIO and a state. If that GPIO is at the specified state when
the device is reset, the ROM boot loader is invoked. See the BOOTCFG register section in the
device data sheet for more details.

3. The user application can invoke the ROM boot loader with an interface specific ROM API. Doing
so forces the ROM boot loader to use only the chosen interface to look for an update.
If a valid application is not found, the ROM boot loader starts execution by scanning the supported
communication interfaces until it receives a valid command to download firmware through a specific
interface. If multiple interfaces could be detected, the sequence that they are checked is: USB (if
applicable) > Ethernet (if applicable) > I2C > SSI > UART. However, this sequence does not
ensure that a specific interface is selected ahead of the others, as all that matters is when the first
received command comes through a given interface.