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.

Chinmay,

I would recommend that you first get your application running with DHCP enabled in the application and connect the LaunchPad and PC (with LM Flash Programmer) to the same router. Once you have this working you can try static IP.

Sai

Hi Chinmay,

>Memory browser I do see the chip being programmed from 0x00004000 location

Not sure by reading your post did you flash the BL offset = 0x0000.0000 but first modify the (bl_config.h ) set the ASA,VSA,FPS all the same 0x0000.4000 then flash the application to offset 0x0000.4000?

>I can see the magic packets on wireshark but LM Flash Programmer is stuck on attempting to connect

The Magic packet is the BL bootP client sending a request to the server (LMFP) and it did not respond.

Think but not yet confirmed LMFP will not communicate via Ethernet to the target LP unless you first load the DFU driver for windows. If WIndows7 select Run, type (hdwwiz), next > search, next > have disk , show all device, have disk, browse to Tivaware Windows drivers, select Device Firmware Upgrade.

BTW: Once the BL is installed you no longer need LMFP to flash the LP if the windows Ethernet client has a TFTP server to go get the binary on the hard drive and send it back to the BL TFTP client. That involves invoking the BL from within the application. BL soft resets the MPU into the firmware update interrupt handler vector within BL.

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

Chinmay,

Try the following:
Program the binary "boot_emac_flash.bin" from "<Tivaware_Install_Directory>/examples/boards/dk-tm4c129x/boot_emac_flash" into a DK-TM4C129X or EK-TM4C1294XL board. Then, using the above flash-based Ethernet bootlaoder, program your application "boot_demo_emac_flash_modified" (using the procedure described in my first post).

If the above procedure works, then the problem is with the bootloader code that you have written.

Thanks,
Sai

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.

Hello Sai,
Firmware update did not start with the emac_boot_flash.bin file from the original directory.

Hi Chinmay,
You raise some good points. We use a Windows GUI to invoke BL update from the outside in. That is to say the GUI sends a command to the application which invokes the BL interrupt vector. Would have to guess LMFP sends a similar command to your application, it decodes the command and invokes the BL update cycle. To me that makes LMFP a TFTP file server and the target LP a TFTP client.

>I flashed the bootloader first
Second time to asked still no response; BL offset address = 0x0000.0000?

>Also in my application firmware linker file I have changed .vtable : > RAM_BASE to .vtable : > APP_BASE .
We only need change the APP_BASE pointer offset to 0x0000.4000 so the BL knows to vector into ASA for it is written (.vtable > APP_BASE).

>1.LMFP sends the magic packet to the LaunchPad.
I have been seeing the application invokes BL asserting Interrupt 2C. The BL update function sends out a Boootp request Magic packet requesting a remote TFTP server to send Update binary file. Supposedly BL is said to have a TFTP server but do question when it would be used. The server by definition has control of the file and LMFP technically should be the server being it fetches the binary from hard disk for the TFTP client requesting update.

The application is requesting BL update asserting interrupt 2C which then invokes (bl_flash.c) to write the binary packets sent via wire transport from the TFTP server in this case LMFP. If a client can access hard disk then I learned something new today.

BL vector 0x2C (word UpdateHandler - 0x20000000 ;; Offset 2C: SVCall handler)

Hi BP101,
Sorry to miss out that for second time for BL the offset is 0x00000000.

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

Hello BP101

There is no RA3 silicon. The issue in the API was for RA0 silicon which has been fixed for RA1 and RA2 (production)

Regards
Amit

I did commented it out and it did not work.

My Ethernet setup involves a switch which has 2 PC, an Ethernet connection from router and my launchpad board. Could there be some problem with it?

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

Chinmay,

Does your set-up have a DHCP server? Normally Ethernet switches don't have a DHCP server.

I would recommend that you configure you PC and Connected Launchpad code to work as DHCP clients. Then connect them to a router. This will ensure that they get an IP address.

To test run the "enet_io" example on Launchpad. Check if it gets an IP address dynamically (DHCP). Then open a browser in your PC, enter the IP address of the Launchpad and see if you can open a webpage. Once this works, try the bootloader.

Sai

Hi Amit,
We confirmed RA1 silicon was being effected by the RA0 patch. Later discovered the Symbol in the project was set to RA0 silicon and the compiler was asserting the patch even after we upgraded to RA2 silicon device. Meant to say revision i3 MPU not RA3.

>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

Thank you for the code. I will include this code in BL and check if it is been invoked or not.

Chinmay

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.

Thanks have been tied up myself not able to get back to BL issue. Its was working with the GUI built in TFTP server. Wire Shark captured other devices in my network responding to the BootP request but not the GUI TFTP server. Then I notice the low level DFU was failing warning code 10 likely caused after a MS Security update patch was installed is my guess.

Hi Chinmay,

With reference to your post several months ago entitled "Ethernet firmware update/bootloader problem", were you ever able to configure the Ethernet ROM based firmware update function without the need of a DHCP server? I will have a unit located were there is no DHCP server so I will be using a fixed IP address.

Thanks,
Alan

Hello Alan,

I have not worked on that project since my last post in this thread. My plan was to do it with DHCP server and then try and get it working with a static IP. But, I was not able invoke the bootloader itself (Although I could see magic packets on Wireshark). After that I was switched to some other project. So I am sorry, I can not help you in this.

Thank you,
Chinmay

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 Chinmay,

I just used the "LM Flash Programmer" version 1613 and ROM Ethernet bootloader to load a small binary "blink.bin" into Connected LaunchPad. I used MAC address similar to "00-1A-B6-xx-xx-xx" for the field "Client MAC Address". The binary was successfully programmed and the LED starts blinking. I also captured the Wireshark log and I don't see the error you are mentioning - about MAC address corruption. The MAC address of the Connected LaunchPad is as expected.

I then tried the same experiment with the Flash Ethernet bootloader from TivaWare 2.1.2.111, located in the folder "examples/boards/dk-tm4c129x/boot_emac_flash". The application code is located in the folder "examples/boards/dk-tm4c129x/boot_demo_emac_flash". Again the application programmed successfully and I did not see any corruption of the MAC address.

Could you share the Wireshark log so that I can better understand if this is some fault with "LM Flash Programmer".

Please refer the application "examples/boards/dk-tm4c129x/boot_demo_emac_flash" to see how to invoke the Flash Ethernet bootloader. That might help in understanding the issue you are facing.

Thanks,
Sai

Hello Sai,

I had not saved the wireshark log containing the magic packet. So I went back to try and repeat the same thing on LMFP but even I did not see the MAC address problem. It was giving out correct MAC address in the magic packet in both formats. While trying this I intentionally added a white space in front of the MAC address and that caused the wrong MAC address in the magic packet. So it seems that if you have a white space at the start of MAC address LMFP considers it as a "00". I might have overlooked that white space and I should have have checked my setting properly before posting about this. I apologize for this mistake and thank you for helping out.

In the boot_demo_emac_flash code I inserted a UART line to print the acquired IP address after the SetupForEthernet() function call and inside the while loop. The device is not acquiring IP address even after initialization. I loaded the the board with enet_io example bin file with Ethernet bootloader and it did work and acquired IP address. I am looking at the LwIP codes to find out what I might be missing.

Thank you
Chinmay.

Hello Chinmay,

Are you sure that the application code is programmed and running? Toggling a GPIO or LED is the best way to check this.

Are you using a custom hardware? If so, did you ensure that all the code related to the display (of the DK-TM4C129X) is removed.

Did you ensure that the UART print statements are actually printing? If this is working, then an easy way to debug is to use print statements at different stages of the application code. This will tell where the application is getting stuck.

How did you ensure that the IP address is not being acquired? Is it possible that the execution never reaches the while loop?

Thanks,
Sai

Hello Sai,

I am using the EK-TM4C1294XL LaunchPad board and I have commented all the display and usb related code. The UART statements are printing normally. I have also tried including print statements in the while(!g_bFirmwareUpdate) loop and and they do print normally.

The function lwIPLocalIPAddrGet() returns -1 which tells me that it has not yet acquired the IP address.

With the help of the UART statements I was able to track the execution of code. The code is stuck in the while loop and never comes out of it. The execution is never interrupted to call SoftwareUpdateRequestCallback function which changes the variable g_bFirmwareUpdate to "true". So the bootloader is not invoked. I did monitor Ethernet activity with wireshark and saw the magic packets coming through.

Just to try I changed the LwIP initialization function to use static IP and with the corresponding changes in LMFP I gave it a try, this time the SoftwareUpdateRequestCallback function was called, the variable g_bFirmwareUpdate was changed to "true" and the bootloader was invoked but the device became non-responsive.

Thank you
Chinmay Admane.

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.

Have noticed a few emails this post and your attempts of static IP - It seems from wire shark trace Bootp request for TFTP server uses all 1's MAC address broadcasts up until the TFTP server ACK's the TM4C client request ( you stated file name returns) where to LMFP? Believe according to the RFC the Boot Loader client then switches into IP packet mode to RXD the incoming data file in 512 byte block packet transfers.

We don't use LMFP instead a GUI windows client allows user to select the file from host PC sending back to the TM4C client. GUI invokes the BL firmware update interrupt in the main application. That 1st Boolean switch may have been doing more than some believe it was doing after soft boot. File transfer was working on the TM4c, believe until I migrated the original Stellaris ware Boolean switch method in the while loop at the bottom of (main.c) and it stopped working much in the way you claim.

Perhaps you may need to include more heap/stack space in the project link section depending if you don't enable (UART_ BUFFERED=1) in the predefined symbols section.

Be sure the network address of your static IP is the same at both ends for example 192.168.xxx.xxx?