Other Parts Discussed in Thread: UNIFLASH
Possible complete scenario for ETHERNET BOOTLOADING / Firmware Updating on a TM4C1294xxxxx based IoT board. For the first time this will happen from inside our shop / factory and from then on from anywhere on the internet. Please advice if this is a correct reasoning. Thank you
1) As we receive our empty IoT boards from factory, either via LM Flash Programmer + EK-1294XL Launchpad configured as out-JTAG programmer, OR via UniFlash + XDS100v2 programmer (assuming our board is equipped with a JTAG port) we program a MAC on a board.
2) Then we use a tiny app that just loads once on our board and what it does is to just go and write to a specific EEPROM location, let’s say 1025 / 0x0401, a 1.
3) Then we load the flash_emac_bootloader app with some minor modifications.
- Checks in certain EEPROM locations to read IP, SUBNET, GATEWAY, that of course they don’t exist at this time and since all of them are NULL uses 192.168.3.10 (or whatever else) as its own IP.
- Checks in EEPROM position 0x0401 if there is a 1, which is the case for the first time from step 2. Then makes it a 0 and proceeds with the rest of the code waiting for our main app’s firmware to load.
- After our main app loads and board reboots, bootloader does not any more find a 1 at the EEPROM location mentioned above and so directly hands control to our main application.
- At that point in time our board has it’s own MAC from step 1 and the IP 192.168.3.10 from step 3a.
4) Our application among other things also runs a TCP/IP server waiting for connections. We use our pc/laptop, at the moment configured with IP = 192.168.3.20 and connect to it via a TCP client like Hercules or other
5) We can now send to our IoT board’s firmware commands like IP=……, subnet=……, gateway=…… that reflect to our network’s actual parameters. All these are written in certain EEPROM locations. At that point we can instead program the IP, Subnet, & Gateway of our client’s internal network who will buy our board. So, at the next boot not only our main’s firmware TCP/IP server, but also our bootloader, will both load and run as full internet units behind a router that will be NATed for port 9-UDP for firmware receive and whatever TCP port we choose for our main firmware’s TCP/IP listening server.
6) The TCP/IP server part of our firmware that listens for commands like IP= e.t.c can also monitor for a command of the type BOOTLOADING=
7) Now our IoT board can be sold and start doing what it is supposed to do. If at a later time we come up with a new firmware and we want to upgrade the remote board, we simply connect to IoT board's TCP/IP server and we send the command BOOTLOADING=1
8) Our firmware, when receives such a command, writes a 1 to the pre-mentioned EEPROM location and issues a ROM_SysCtlReset.
9) Now, the bootloader reading to that EEPROM location finds a 1 which means that enters in the waiting state for receiving a new firmware, after of course it has write a 0 to that EEPROM location.
Provided that NAT has been adequately configured on the client’s router and our firmware is fully fortified with passwords and other means so to accept, validate and run the remotely send over internet commands, seems that we have a fully working method for internet firmware updating. Is it so?
