This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

EK-TM4C1294XL: TCP Bootloader for TM4C1294xxxxx Boards & Modules v.1

Part Number: EK-TM4C1294XL
Other Parts Discussed in Thread: ENERGIA, TM4C1294NCPDT,

Hello all.

Almost a bit more than a month after and a couple of hours per week available to work on the project and mainly thanks to the precious help of Bruno, Charles, Bob, Amit, cb1_mobile and all the other nice guys here at the forum, I managed to have a fully operational TCP ethernet bootloader build from scratch. At the following link you can download all source and also helpful guidelines to understand and have the project up and running in minutes. In case something is not clear, please post here. Project is ready to by compiled and/or directly run for/from both CC7 & ENERGIA IDEs. Has been tested succesfully for over 100 bootloads and firmware upgrades so far. Link for downloading:

This tcp_bootloader seats at 0x00000000 for as long we wish and can for ever  peacefully coexist with other TIVA ROM bootloaders that can be triggered on demand by our source as usual. The main merit of this bootloader is that does not need a guy to be near the module for the firmware load/update to take place. One can be miles or continents away and instruct his/her remote module to enter in an update loop and then auto-reboot in the updated or any other new application. Hope some folks will find it useful.

All the best

John

  • Hi John,
    Thanks so much for your contribution to the community. It will greatly benefit many people looking for the same solution. Once again, THANK YOU!
  • Charles it's my pleasure to share good knowledge with people that also contribute in favor and for the benefit of the community. After all, TI, since the TI-58 and TI-59 era, always was a company that I was admiring. My very-very-very first program, the game 3-5-9, was built and successfully run on the TI-59 in a 850 or something steps program and was recorded on a, through a zzzzzzzz sounding magnetic reader, mustard yellow colored magnetic card. It was a MARVEL. I wish I had never sold that TI-59 unit with the printer.

    I hope that the bootloader/firmware-updater program will help some people. I also hope that I have not overlooked critical details of the processor and no serious mistakes have been done. The processor's book and the TIVA library's books along with VALVANO's 3-books and also Joseph Yiu's definitive guide to Cortex-M3/M4 processors helped me a lot to understand the inner workings and the philosophy of this TM4C1294NCPDT dude. The potential of this unit is truly almost limitless.

    Please let me know asap if foolish mistakes exist in my code. That way we can make this collective effort's product to eventually turn into a very powerful managerial tool for farms of processors of the M4 type and of other types of equivalent processors.

    All the best to all,

    John 

    P.S. In the C# TCP client application you may need to modify the command byte[] BytesReceived = new byte[the_length]; to byte[] BytesReceived = new byte[the_length+1];  For some peculiar reasons under different .NET runtime versions seems that string-stream-buffers are differently handled. Seems that, for historic-C reasons the byte[] BytesReceived = new byte[the_length+1]; is a safer approach.

  • Thank you John. Your project seems very cool!

    I have an issue when trying to compile project "tcp_bootloader" in CCS v7:

    Buildfile generation error occurred..
    This project was created with Energia v0.0, which is not currently installed and no compatible version is available. Go to Preferences > Code Composer Studio > Products to register a compatible version of Energia.
    Build stopped..

    Under preferences/product I have the configuration as in the following image:

    Any idea how to solve it?

    thanks

    Simone

  • 
    No problem Simone.
    Just go to the energia.nu and download and install the latest version.
    It's small and slim. You may never use it again apart from this compilation.
    Or you may find it handy for small projects.
    In any case, after download & install just give the ENERGIA's root installation
    directory to CCS7 and that's about all. You'll then get your bin at once.
    I created this project for both CCS7 & ENERGIA communities so both can use it.
    What is included in ENERGIA are some reduced size libs of the original TIVAWARE.
     
    I have also slightly correct the ethernet server libs to accept server port change
    at runtime. For both EEPROM & ETHERNET compilation, use those included in my zip.
     
    John
     
     
     
     
     
    -----
  • I know Energia IDE, and the benefits of it. I like it very much for small simple projects in fact.

    As you can see in the picture I already have "energia-0101E0017-windows" on my PC, which gives the aforementioned error.

    I also tried to download "energia-1.6.10E18-windows" (latest version) and modify the root directory in CCS, but the same error persists:

    Buildfile generation error occurred..
    This project was created with Energia v0.0, which is not currently installed and no compatible version is available. Go to Preferences > Code Composer Studio > Products to register a compatible version of Energia.
    Build stopped..

    Moreover, with this new version of Energia, also projects lptm4c1294ncpdt_core, lptm4c1294ncpdt_EEPROM, lptm4c1294ncpdt_Ethernet are not compiled, resulting in the following error (e.g. for the first libary):

    Buildfile generation error occurred..
    The board-ID 'lptm4c1294ncpdt' is not recognized. It is either invalid, or is not supported by Energia v18.0.
    Build stopped..

    (maybe for this last issue i have to download libraries in the Board manager of Energia)

  • Installing TivaC Boards in Energia IDE solved the issue with lptm4c1294ncpdt_core, lptm4c1294ncpdt_EEPROM, lptm4c1294ncpdt_Ethernet.

    But the compilation problem with main project "tcp_bootloader" still persists.

    regards,
    Simone
  •  Just to be sure that I perform correctly the projects import process:

    1) unzipped the content of you rar file

    2) import CCS project in CCS 7 (from your folder to my workspace) with the settings shown in picture 

  • Apart from the technical problems during compilation of the bootloader, I have a few questions:

    1) when you say "The main merit of this bootloader is that does not need a guy to be near the module for the firmware load/update to take place. One can be miles or continents away and instruct his/her remote module to enter in an update loop and then auto-reboot in the updated or any other new application."

    what do you mean? I had a look at the sendFile TCP client application, and have seen that it takes as input the local IP address of the board on the LAN. How can I reprogram the board over the internet, when far away from home? Which parameter should I set?

    2) where can I set the password for the firmware update? / which is the password default value?

    3) if I understood well in my main application running on the board I have to introduce some functions to manage a TCP server: do you have any sample (and simple) application implementing such functions?

    thank you

    Simone

  • Hi Simone.

    1) By simply changing the IP address and/or port in the text-boxes when client application starts, before or after you have chosen the bin file to send. If you check the source code is all there. After the firmware upload you can repeat with another IP/port combination without exiting the client app. IPs may be from LAN, or WAN provided that the remote router where the TM4C is behind is NATing and/or PATing.

    2) I have not coded a password default value for the client and TM4C and the module. You can put anything you want in the client app and in the firmware. You can do the check before or after my code for communicating the file-size. 

    3) The TCP server function & functionality are already coded in the bootloader's source. Just repeat it in your main firmware app's code. 

    I don't see in this forum's thread the other answers I send you in the afternoon! 

    Have a good night,

    John

  • Sorry if I bother you with so many questions, but I'm a little confused, especially about my question 3).
    So please confirm me if I understood well the steps from the documentation:
    a) complile the tcp_bootloader and flash it to the empty board once with lm flash programmer
    b) the first time, the BOOTLOADING location on Eeprom will have value 0x1 (?) so the board (on which only bootloader is installed, no main app) will automatically enter bootloader mode and wait forever for a tcp connection
    c) one day X I decide to load an application (let's call it ALPHA) on the board: just have to include into ALPHA the functions to manage future app update/replacement, and then I can use the tcp client application to send the file to the board. The application is written on flash by bootloader, then bootloader writes 0x0 at the BOOTLOADING location and restarts the board. By finding 0x0 the control is passed to main app ALPHA that will run normally
    d) one day Y I decide to replace ALPHA with BETA. In the same way I have to include into BETA the functions for TCP request management (for future app updgrade/replacement), compile the app and load it by means of TCP client application. Then it will act as in c)

    My question, apart from the one at b), is:
    I was looking into the bootloader code in CCS, but I can't find which are the functions that shall be copied into the main app ALPHA / BETA. E.g. in which function the BOOTLOADING location is written with 0x1 value? Or in which function ROM_SysCtlReset() is called? More in general could you please provide identification of which are the functions of tcp_bootloader which I should include in a simple program like this (the blink example in Energia):

    // most launchpads have a red LED
    #define LED RED_LED
    //see pins_energia.h for more LED definitions
    //#define LED GREEN_LED

    // the setup routine runs once when you press reset:
    void setup() {
     // initialize the digital pin as an output.
     pinMode(LED, OUTPUT);
    }

    // the loop routine runs over and over again forever:
    void loop() {
     digitalWrite(LED, HIGH);   // turn the LED on (HIGH is the voltage level)
     delay(1000);               // wait for a second
     digitalWrite(LED, LOW);    // turn the LED off by making the voltage LOW
     delay(1000);               // wait for a second
    }

    PS: neither I can see your answers, so I'm still having problems with compilation of bootloader in CCS.

    many thanks

    Simone

  • Hi Simone. I'm on business travelling so I can't focus well on all issues. But when you import cpp code from other IDEs into CCS, all comments are lost and replaced with empty lines. Something I don't know why is happening. Read my original source code through a notepad++ or other editor and you'll see all comments there.

    --- The first time, EEPROM location will be 0xFF = -1, not a 0x00, so bootloader will be waiting to receive an app. In c) & d) you are correct.

    --- You just need to include the commands to start and have a TCP server always running in the blink app. That way you'll be able to connect to the app in the future and give a command so the app will parse it and will write a 0x01 in EEPROM bootloading location and issue a reboot. Then you can remotely load any other app you want.

    I can't be of more help until Saturday, but everything is straightforward to study and follow. Simple steps one-at-a-time.

    John
  • Still having problems with the tcp_bootloader compilation in CCS, that makes it hard to debug and fully understand the code. So I have one question: when I flash the bin of the BL and then start Tera Term, i see the following:

    "My local MAC is: 0x00-0x1A-0xB6-0x02-0x55-0x99
    My local IP is: 192.168.70.55
    My SUBNET Mask is: 255.255.255.0
    My GATEWAY Address is: 192.168.70.254
    Local Server's Listening Port is --> 11111"

    but I'm sure that neither the MAC address nor the IP are the real value of my board (MAC address is printed on the board, and I can also retrieve it with LM Flash Programmer; as regars the IP addres, from my router page I can see a different IP assigned to the board). When I try to load an application with the tcp client, the download does not succees.

    Which values shall I put in the tcp client app for IP address and port? Default values are 192.168.12.12:1002, but also this IP address is different from the 192.168.1.68 I see in my router's page.

    I do not understand which is the sense of value 192.168.70.55, too. This seems a value printed in the source code, but with no link to the real IP value of the board.

    And what about the port value? 1002? 11111? Another value?

    Thanks

    Simone

  • Dear Simone hello.

    Your client PC and the IoT module in order to be able to communicate for the first time over ethernet, they need to step on the same subnet. In my code the addresses that are define may be changed so to make the IoT module boot in the same subnet as your PC. It's a plane net settings issue. You need to recompile the bootloader app of course and flash it with LM on the IoT module. After your IoT module boots you'll see addresses from your (new) subnet to be displayed and then you can start transferring the app's bin image from your PC to the IoT module..

    ****** Try to make this succeed  for the first time and THEN try the same over internet. Port doesn't matter if it is 11111, 1002 or whatever else. You only need to have configure NAT on this port and on IoT's internal IP on your router. *******

    To make things easier for the first time, use LM to flash the bootloader bin that I include in my post and then configure your  PC's LAN settings on the same subnet as IoT. (Put your PC's IP=192.168.70.10 subnet=255.255.255.0, gateway=192.168.70.1. On the PC app just change in the textboxes the IP and the port to meet those of the IoT module, if already not displayed. That's all. Also, don't forget that in order for your app's bin to run correctly after the bootloading / after reset  / after firmware upload, it must have been compiled for the upper addresses in flash, as I explain in detail in my notes.

    **** MAC address can be ANY that you want to define in the source of the bootloader, the one that is already coded, or add a routine as in the TIVA examples to read it from the USR registers. Doesn't really matter for the moment and at large. Ethernet to operate successfully, just NEEDS only a MAC. NOT A PARTICULAR MAC. Doesn't matter if the factory MAC is different with that in the boot-loader's or your app's code. Your module will be exposed as a server with the MAC that you define in the server start command. *****

    Good luck on this,

    John

  • Hi John,
    1) why do you say that my gateway shall be gateway=192.168.70.1 ?
    Shouldn't it be the IP address of my router? (that is different from 192.168.70.1)

    Please note that if I modify TCP/IP v4 settings in my PC as you suggested my PC is no longer able to connect to my router.

    2) within functions read_my_mac, read_my_ip, read_my_subnet, etc. the BL looks if certain EEPROM locations are empty or not. In case they are empty (as after BL flash), the terminal always shows "My local MAC is: 0x00-0x1A-0xB6-0x02-0x55-0x99" / "My local IP is: 192.168.70.55" / "My SUBNET Mask is: 255.255.255.0"., etc. So, what do you mean when you say "After your IoT module boots you'll see addresses from your (new) subnet to be displayed"? In my opinion even if I change the init value of the following in the source code:

    byte my_mac[] = { 0x00, 0x1A, 0xB6, 0x02, 0x55, 0x99 };
    byte my_ip[] = { 192, 168, 12, 12 };
    byte my_gateway[] = { 192, 168, 12, 1 };
    byte my_subnet[] = { 255, 255, 255, 0 };

    the terminal will always show this:

    "My local MAC is: 0x00-0x1A-0xB6-0x02-0x55-0x99
    My local IP is: 192.168.70.55
    My SUBNET Mask is: 255.255.255.0
    My GATEWAY Address is: 192.168.70.254
    Local Server's Listening Port is --> 11111"

    unless someone writes in the EEPROM locations.

    By the way, I think there is an error within function read_my_gateway, because location MY_SUBNET is checked instead of MY_GATEWAY.

    Unfortunately I cannot modify the bootloader and recompile it because I still got the error:

    "Buildfile generation error occurred..
    This project was created with Energia v0.0, which is not currently installed and no compatible version is available. Go to Preferences > Code Composer Studio > Products to register a compatible version of Energia.
    Build stopped.."

    thanks for your support
    Simone

  • Hello Simone.
    The terminal will always show this "..." because these are the default values if other values have not yet been written in EEPROM. If you check the source and the guide document carefully answers are in there. If not I'll be glad to assist you further.
    Just make sure, IoT, your PC and the router are all on the same subnet. That's all you need to verify.
    Download and install ENERGIA 17. That will solve your compilation problem. (Remember to replace the ETHERNET cpp & h with the ones I include in my rar )
    That should work in any case.
    John
  • With Energia 17 (I suppose you mean energia-0101E0017) now I have the following error:

    **** Build of configuration Debug for project tcp_bootloader ****

    "C:\\ti\\ccsv7\\utils\\bin\\gmake" -k -j 4 all -O

    'Building target: tcp_bootloader.out'

    'Invoking: GNU Linker'

    "C:/Dati/Download/Elettronica/Energia/energia-0101E0017-windows/energia-0101E0017/hardware/tools/lm4f/bin/arm-none-eabi-gcc.exe" -fno-exceptions -DF_CPU=120000000L -DENERGIA=17 -DARDUINO=101 -Os -ffunction-sections -fdata-sections -fsingle-precision-constant -g -gdwarf-3 -gstrict-dwarf -w -Wall -fno-threadsafe-statics --param max-inline-insns-single=500 -mabi=aapcs -march=armv7e-m -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -Wl,-Map,"tcp_bootloader.map" --entry ResetISR -nostartfiles -nostdlib -Wl,--gc-sections -L"C:/Users/Simone/workspace_v7/lptm4c1294ncpdt_EEPROM/Debug" -L"C:/Users/Simone/workspace_v7/lptm4c1294ncpdt_Ethernet/Debug" -L"C:/Users/Simone/workspace_v7/lptm4c1294ncpdt_core/Debug" -L"C:/Dati/Download/Elettronica/Energia/energia-0101E0017-windows/energia-0101E0017/hardware/lm4f/cores/lm4f/driverlib" -Os -Wl,--check-sections -Wl,--unresolved-symbols=report-all -Wl,--warn-common -Wl,--warn-section-align -fsingle-precision-constant -o"tcp_bootloader.out" "./tcp_bootloader.o"  -Wl,--start-group -Wl,-T"C:/Dati/Download/Elettronica/Energia/energia-0101E0017-windows/energia-0101E0017/hardware/lm4f/cores/lm4f/lm4fcpp_snowflake.ld" -llptm4c1294ncpdt_EEPROM -llptm4c1294ncpdt_Ethernet -llptm4c1294ncpdt_core -ldriverlib -lm -lc -lgcc -Wl,--end-group

    makefile:154: recipe for target 'tcp_bootloader.out' failed

    ./tcp_bootloader.o: In function `setup':

    C:/Users/Simone/workspace_v7/tcp_bootloader/tcp_bootloader.ino:146: undefined reference to `EthernetServer::SetPort(unsigned short)'

    collect2.exe: error: ld returned 1 exit status

    gmake[1]: *** [tcp_bootloader.out] Error 1

    gmake[1]: Target 'secondary-outputs' not remade because of errors.

    gmake: *** [all] Error 2

    makefile:145: recipe for target 'all' failed

    **** Build Finished ****

    In the picture the linked resources of the tcp_bootloader project. Highlighted in yellow are the two libraries in Energia that I replaced with your source code.

    Anyway, if I would like to use your BL bin, without any modification and recompilation:

    I think my board, router and PC are all in the same subnet (all IPs start with the 192.168.1) but the download from client app does not succeed.

    Could you please clearly state which IP value shall I provide in the textbox of the SendFile.exe? Which of the following:

    a) the IP that is assigned to my board (as I can see in my router's page)

    b) the value 192.168.12.12 (as per byte my_ip[] = { 192, 168, 12, 12 };)

    c) the value 192.168.70.55

    Regards

    Simone

  • Simone, replace the contents of the two dirs, ETHERNET & EEPROM with those in my rar. Then re-compile.

    No IP can be assigned to your board from the router, because the IP of the board is either taken from EEPROM or the default from inside my source wich is 192.168.12.12 Unless you set and compile in the code an IP from your subnet, communications will not be possible. What I would suggest again, is to change for a while your PC's IP to 192.168.12.200 (for example) and then try to connect by giving to the textbox of the SendFile.exe the 192.168.12.12 and the port that is in my bootloader source code which is 11111.
    John
  • Finally I managed to compile the project in CCS! By removing from workspace the projects "lptm4c1294ncpdt_core", "lptm4c1294ncpdt_EEPROM", "lptm4c1294ncpdt_Ethernet", and then compiling "tcp_bootloader" the 3 above mentioned projects are automatically re-imported, and now the process works.
    Being able to compile the source code I have modified the default IP value, mac value and gateway value.
    Now the local (LAN) connection between client app and the board works and I'm able to download an application, even without having to modify IP address of my PC.

    I will now experiment with the update through the Internet. Basically I have to configure my router to forward traffic on TCP port 11111 to the IP of my Board, is it correct? And then in the client app I have to provide my public IP address?

    Thank you very much John,
    Regards,
    Simone
  • Simone EXCELLENT !!! Bravo.

    Yes you need to open the 11111 port on your firewall. You can even change that port number in the source to whatever does the job for  you. Anything between 3550 < my_port < 65000 should be fine. And yes, you provide the p[ublic IP of the router behind which the IoT module is found. However, have in mind that if your PC uses the same router to exit to internet, it might be no possible to connect. The PC now needs to step on a subnet outside the LAN that IoT module is found. That's all and that is the reason why I coded this piece of software. Have fun.

    All the best,

    John

  • Thank you John.

    Just one question about main app, in order to make it able to update itself.

    In your document you say:

    "The main application running on the EK-TM4C1294XL or similar boards should host a TCP server slim functionality that listens for a remote command of the type, update_firmware_password, where password is anything one wants to send to the IoT’s main app’s TCP server to verify that is a validated operator to initiate and execute a firmware update session on the IoT.

    The main running application on the IoT, upon receiving the message from remote TCP client app running on a PC, will then do two things: a) write a 0x01 at EEPROM’s BOOTLOADING location, b) execute a ROM_SysCtlReset();"

    Who is that send update_firmware_password to the board? Your tcp client app? Or I have to arrange another app/strategy to send this message to the board?

    Thank you

    Simone

  • O.K. Simone. The way it works is based on the fact that when the developer of the main_app's firmware releases a new main_app's firmware version, needs to have a mean to transfer this new firmware to the remote IoT module. Correct? So every version of the main_app's source/firmware, must host a routine able to receive a remote 'signal' that can be interpreted by the code as: < O.K. I stop everything I'm doing, I'm writing a '1' at the EEPROM's bootloading location, and I reboot - "application says to itself"> The only out-of-the box way that TM4C1294xxxxx boards can make this happen is through the ETHERNET port. So, regardless of what our main_app's code/firmware does, we need to have a routine as I said, a TCP server-listener for example, (anyway we may already employ such a functionality if our main_app needs it for other purposes) checked periodically from the loop() or via interrupt handling,
    for the case of a remote update request of the type "update_firmware_password" or whatever we choose it to be. The same PC  that performs the firmware update may  be the one that connects to our remote module's TCP listener (in the main_app) to notify it for the request for a firmware update. For doing this notification you can even use a puTTY or any other TCP/IP enabled terminal utility. Or you can even modify at will my C# code and make it happen easily from inside this interface adding a couple of more buttons and some connection functionality.
    I hope everything is clear now.
    John

  • Ok, now it is very clear. At first I thought that the command to notify incoming update was already sent by your client app.
    Since my main app uses MQTT protocol, I added to it the management of a special topic "update" to perform the two operations of writing a '1' at the EEPROM's bootloading location, and reboot. Then the bootloader starts and I can use your app to transfer data. And everything works fine in local network.

    I noticed that when I try to upload new app throught the Internet the first block (2048bytes) is transferred, but then it gets somehow stucked and the next blocks are not transferred, then the Bootloader restarts after a while. Maybe I have to increase the WatchDog timer, or refresh it more times during TCP transfer process.

    thank you very much for your work and your help
    Simone
  • Hello Simone. By now more than 400 over internet updates have been successfully accomplished for our company's modules already spread in various installations. However, for us also, in about 7 cases the over internet update failure. We just simply repeated it and everything worked fine.  I know that there is a not yet confronted demon(bug) that lurks either inside the 1.4.1 implementation of the TCP stack or most probably inside the TM4C1299NCPDT PHY implementation of buffers's handling, that emerges under certain internet traffic conditions. Maybe there  is not a bug, but some unknown to me issues need to be specifically considered when coding TCP on the TIVA hardware. As a matter of fact, unless I have overlooked this, until now I haven't seen any other pure TCP/IP big file transfer implementation for the TM4C1294xxxxx μC modules.  Also, using the same exactly software stack, the lwip 1.4.1, for coding embedded internet communications for file/firmware  transfers on another 32-bit μC of the competition, I never had any such problems. A colleague of mine who is also developing on this other 32-bit μC's platform never had such a problem. I have seen his C code working, which is a copy of mine for this TCP/IP internet transfer case, and he had no problems so far. I would say that it would be great if, TI people that support Tiva-C modules like this TM4C1294xxxxx μCs, decide to code a TCP/IP file transfer lib and show to us how we should properly handle this stack. I mean, if TI really wants to promote this Tiva-C series modules on which wisely decided to include a PHY ETHERNET interface, would it be logical to also offer an example for the TCP/IP stack? (HTTP is stateless and thus one will never face such problems like communication hangs) Unless I miss something, I think that lwip 1.4.1 needs a TCP lib modification to exactly fit the PHY implementation of the TM4C1294xxxxx modules. I tried on this very hard 2 months ago and although I have 27 years of experience on TCP/IP & UDP network programming in both application and (mainly) embedded level I couldn't identify the cause of those random hangs. My experiment was to use the EK-TM4C1294XL as a TCP/IP receiver of big files from one PC on the internet and also a sender of this file's parts to another PC on the internet. In 3 to 4 out of 10 tries module hanged! With UDP no problem. With TCP problems! I wan't spent any more time on this, unless TI guys want to tackle with this issue. If you have frequent hangs over internet, just modify both my embedded and C# codes for 1024 or even 512 bytes data packets. Slower but without hangs.

    Simone, you said you are using the MQTT IoT packeting protocol. What version? Are you doing ZigBee stuff? You must have seen so far that since this is a TCP/IP based protocol for tiny blocks of data that everything works just fine. Isn't it so?

    All the best,

    John

  • Hi John, thanks for your considerations and advices.

    As regards MQTT, I'm using the library provided with Energia 17. Some months ago I developed my main application (a hobbyst Ethernet-connected device to remotely operate an IR emitter LED for some home devices) in Energia IDE because I find it very simple and intuitive to develope simple applications. To develope the application I have chosen MQTT protocol because it is also simple to "implement" the "control" part on an Android phone for example, since some apps can be downloaded as MQTT client, which require only a minimum configuration phase. I do not know which is the MQTT version included in Energia 17, I can check if necessary.

    My will was to update such main application without the need to disconnect the board from its operating location (since it is difficult to access). For this purpose the TI Ethernet Bootloader (within LAN) or your TCP Bootloader (also outside the LAN) are perfect, so I started approaching them, and finally - with your precious help and patience - I succeeded in having clear what I had to modify in my pre-existing MQTT-based application to trigger the Bootloader. Then the firmware transfer all relies on your BL and on the TCP protocol.

    Hope I have answered your questions,

    regards

    Simone

  • O.K. Simone.
    Good luck to all of your projects.
    John
  • Hello John,
    I am also trying to get my hands on the remote update on the TM4C 1294 Launchpad and came across this post. But the Link to your project file cannot be found. Can you send me the link which you previously posted?
    Regards,
    Nishit.
  • Hello Nishit and thank you very much for your kind reference to my tiny contribution on this platform. I was away from my office on business traveling for some days and only today I noticed your query. Tomorrow that I'll be again at my "vault" I'll manage to upload the project again and I'll send the link to you (forum). I have also coded some good new modifications on the project at both the C# application code and at the boot-loader firmware code. The main idea is: 1) Say that we receive a bare-bone, completely naked from any firmware, TM4C1294NCPDT based controller board from the factory. 2) For this board to be operable, regarding the Ethernet TCP server interface, we initially need to burn a MAC into it as a first step otherwise the run of a TCP server on it becomes impossible. [EK-TM4C1294XL eval-board has already one burned in for us] 3) This can be done only through the JTAG channel. 4) We use an appropriate/compatible JTAG programmer for this programming and also for loading once the TCP boot-loader. 5) From then on you can remotely upload any firmware by just connecting to the TCP server of this boot-loader the functionality of which is described in the documents that are included in the download files.

    BUT, keep in mind that this project is a combined effort of mine and of the excellent help given to me from TI and from other gurus and masterminds in this forum. Help which was given to me in the form of hints after certain progress had been done from my part on the understanding of this platform. Since you are a student as you say, I suggest that you would primarily need to posses a rather good and solid knowledge of this platform's inner workings. Only that way you'll be able to take full advantage of the knowledge that is offered here in this forum.

    As I said, tomorrow I'll re-upload the project and I'll post the link.

    John