Ethernet firmware update/bootloader problem.

Hello Chinmay,

I was able to successfully program the bootloader and application that you provided using "LM Flash Programmer" on DK-TM4C129X board. Here is what I did:

• On the "Configuration" tab use "TM4C129X Development Board". On the "Program tab" browse to "boot_emac_flash.bin" (after unzipping "2388.boot_emac_flash.zip"). The program.
• On the "Configuration" tab use "Manual Configuration" under "Quick Set" section. Then select "Ethernet" from the drop down menu under "Interface" section.
• Enter "MAC address" of the board (present behind the board) and "IP address" of the board (got by running enet_io example). Select the correct Ethernet adapter that will be used by "LM Flash Programmer".
• On the "Program tab" browse to "boot_demo_emac_flash_modified.bin" (after unzipping "boot_demo_emac_flash_modified.zip"). Then hit the program button.
• In about 30 seconds, the application is programmed and LM Flash Programmer shows the competed status.

One problem I see is that the board becomes inaccesable after programming "boot_demo_emac_flash_modified.bin". But I did not debug this issue.

Thanks,

Sai

Hello Sai,

Thank you for replying..!

I tried to follow the steps you mentioned but it did not work for me.

This is what I did on LM Flash Programmer:

1)      Configuration tab: TM4C1294XL Launch pad    Program tab: boot_emac_flash.bin

and programmed the board.

2)      Then I try to do this but the ethernet leds are off so I think the Ethernet interface is not up (it is not there on the interface tab).

Configuration tab: Manual configuration    Interface: Ethernet     Program tab: boot_demo_emac_flash_modified.bin

with IP address and MAC Id.(I am using a static IP address)

Then I tried to do this

1)      Configuration tab: TM4C1294XL Launch pad    Program tab: boot_emac_flash.bin  with Option: Erase Entire flash

and programmed the board.

2)      Configuration tab: TM4C1294XL Launch pad    Program tab: boot_demo_emac_flash_modified.bin with

Option: Erase necessary pages and Offset: 0x4000.

and programmed the board.

the Ethernet leds are blinking so the interface is up.

3)      Configuration tab: Manual configuration    Interface: Ethernet     Program tab: boot_demo_emac_flash_modified.bin or enet_io.bin

with IP address and MAC Id.(I am using a static IP address)

In this case the LM Flash programmer is stuck on attempting to connect.

Even if I change the order of step 1 and 2 the same thing happens.

I can see the magic packets on wireshark.

Am I missing something?

Thank you 

Chinmay.

Hello Sai,

I enabled the DHCP  and connected the LaunchPad to the same switch to which my PC is connected and redid the entire process.

The launchpad did acquire the IP adresss but still the firmware update did not start.

Chinmay

Hello BP101,

I flashed the bootloader first with ASA,VSA,FPS all set to 0x00004000 in bl_config.h and then flashed the application firmware(which invokes bootlader when it receives magic packet) with offset of 0x00004000.

Also in my application firmware linker file I have changed  .vtable :   > RAM_BASE  to .vtable :   > APP_BASE .

">Memory browser I do see the chip being programmed from 0x00004000 location" >> I mean to say when I try to debug the application code from CCS.

I can see the DFU device in device manager so that would not be a problem.

Please correct me if I am wrong in my understanding of the process:

1. LMFP sends the magic packet to the LaunchPad.
2. Application code invokes bootloader once it receives the magic packet.
3. Bootloader starts the BOOTP server. (LMFP is a client)
4. Then via TFTP the firmware is transfer to to the server(Launchpad).

Thank you.

Great that is correct but wonder why APP_BASE was modified?

For some reason the lines top (bl_emac.c) cause SYSLK to malfunction with RA1 silicon MPU - not sure if they effect RA3 silicon.

//
// Define ROM_SysCtlClockFreqSet() for snowflake RA0. Even though this function
// is deprecated in RA0 ROM, the function operates correctly when
// SYSCTL_MOSCCTL register is configured correctly prior to calling this
// function.
//
//#if defined(TARGET_IS_TM4C129_RA0)
//#define ROM_SysCtlClockFreqSet                                                \
        ((uint32_t (*)(uint32_t ui32Config,                                   \
                       uint32_t ui32SysClock))ROM_SYSCTLTABLE[48])
//#endif

>Ethernet connection from router

Assume you enable a DHCP pool in the router and the client pulls an IP address, think you confirmed is case earlier post and ping the device. That ping is no guarantee a connection on TCP, person in forum is reporting an invalid MAC pings yet will not connect to TCP socket.

>Is there anyway that I could check if the application invokes the bootloader?

Could add a UARTprintf() message to print in APP before invoking the BL in asserting interrupt 0x2c. Might add the lines below to BL as to print feedback to a terminal emulator via virtual COM port. ICDI supports virtual COM port in most the examples, think even Enet-IO.  Add the #define to (bl_config.h) as to enable/disable any positioned UART print messages. Avoid adding UARTprintf to while loops, will flood the channel.

void
UpdateBOOTP(void)
{


#ifdef UART_PRINT_ENABLE
    //
    // Enable pin PA0 PA1 for UART0 U0RX, U0TX
    //
    ROM_GPIOPinConfigure(GPIO_PA0_U0RX);
    ROM_GPIOPinConfigure(GPIO_PA1_U0TX);
    ROM_GPIOPinTypeUART(GPIO_PORTA_AHB_BASE, GPIO_PIN_0 | GPIO_PIN_1);

    //
    // Enable the UART, clear the terminal for printing messages.
    // Set data rate, length, parity, and number of stop bits to 8-N-1.
    //
    UARTStdioConfig(0, UART_FIXED_BAUDRATE, 120000000);

    UARTprintf("<< UART print configured Enabled >>\n");

#endif

    //
    // Get the size of flash.
    //
    g_ui32FlashEnd =  ROM_SysCtlFlashSizeGet();
    UARTprintf("<< FlashEnd = >>%i:\n",  g_ui32FlashEnd);

#ifdef FLASH_RSVD_SPACE
    g_ui32FlashEnd -= FLASH_RSVD_SPACE;
    UARTprintf("<< FlashEnd -ReserveSpace =  >>%i:\n",  g_ui32FlashEnd);
    g_ui32FlashEnd = FLASH_PP_SIZE_1MB;
#endif

I had to switch to some other project and can not work on this so I will work on it and post the results asap.

Thank you for all the responses.

Hi Chinmay,

Thank you for your response. I have found that the LM Flash Programmer starts out with a UDP broadcast and that will not be usable with my project which requires firmware update across the Internet. Therefore I am looking into another means for updating. Most likely I'll be using TFTP and will come up with my own firmware update program.

Hope your other project is working out for you!

Regards,
Alan

Hi Alan,

As you pointed out Boot loader calls the TFTP host server broadcasting a UDP BootP request on the wire. After the BootP TFTP request is answered by a host the caller switches into TFTP client mode. Was my thought as well to have the bin file transported over the internet via TFTP adding 128 bit DES encryption. So it seems the UDP needs to be converted but... UDP is IP protocol friendly and functions over the internet and UDP Bootp broadcast are blocked at the router. Some how - perhaps encapsulate the UDP broadcast into an endpoint the client can unwrap and ACK may be one way to achieve the TFTP connection across the internet. We used TCP encapsulated IPX packets during cloud spoke endpoint conversions over to pure TCP so it seems plausible, how difficult is the question. Perhaps Cisco may now have a way to encapsulate BootP UDP broadcast at the router, off loading that encapsulation part into TCP packets.   

Recall Amit mentioning recently in another post TI is working on a new Boot loader, perhaps it  may have a means to this end? 

Hello BP101,

Thanks for the info. For updating my application over Internet, it would have been nice to jump into ROM and run from there. Now it looks as if I'll need to build a Bootloader in Flash for a Internet update. Some of these units will be on mountain tops and not accessible a few months of the year.

Amit if you are reading this post, anything along the lines of TI working on a new Ethernet Bootloader?

Thanks,
Alan

Hi Alan,

The mountain top (snow caps) you may if not already want to employ a watchdog timer with set enable reset MCU on second timeout. I have two dogs on the watch for SW hick ups and or bugs.  One WD timer is for the TCP application and the other one is for the application accessing several peripherals in several functions. Simply disabled the reset MCU while still debugging code. Kicking the dogs in each APP part keeps the timers from expiring and or asserts high level application blocks to TCP when the IP link fails etc. That link watch dog seems to help LWIP from blowing the heap when or if the link suddenly drops. That link drop during TX data seems to be locking the TX controller or the PHY and often LWIP heap blows up. Seeing that occur a few times started forcing brown outs on the switch to see what would happen.

Hi BP101,

I was intrigued reading your explanation on how you implemented the WD function in your product. I haven't looked into the coding of a watchdog circuit for my product yet, but after reading your discussion now is a good time to do some research and get coding.

Thanks for your discussion.
Alan

Hello BP101,

I was able to invoke bootloader from the main firmware with static IP settings. But the bootloader does not work with static IP settings(I have changed emac.c, uip.c and uipopts.h accordingly). When I observe the packets in wireshark, the board sends the bootp request, the LMFP responds with bootp reply with the new firmware file name but nothing happens after that. Normally it should be followed by TFTP packects which fetch the firmware file. it seems to me that it is stuck in wait for bootp reply loop.

I tried to include the UART print lines in the bootloader for debugging but it does not work. The bootloader does not even sends the bootp requests once I include the UART print lines.

Can you help me out with this?

Thank you,

Chinmay.