• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 78 subscribers
  • Views 1723 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

MSP432E401Y: Ethernet bootloader and software

madphysics
Prodigy 90 points

Part Number: MSP432E401Y
Other Parts Discussed in Thread: MSPBSL

Hi.

I am using the MSP432E401Y in a design that will be networked and without any real other connectivity to the outside world. The plan for in situ update of firmware is to use the Ethernet as the delivery method and in that respect I have a design that uses FreeRTOS and lwip successfully working. (Lwip is used as NDK does not have an SNMP daemon and that is the system's main purpose)

Using the examples given I have copied the "swupdate.c" into my design and that all seems to work fine. I can send it the "magic" packet and get it into the bootloader. This was tested with wireshark and used netcat to send the packet.

echo -ne '\xAA\xAA\xAA\xAA\xAA\xAA\x52\x00\x2b\xa5\xa0\xa7\x52\x00\x2b\xa5\xa0\xa7\x52\x00\x2b\xa5\xa0\xa7\x52\x00\x2b\xa5\xa0\xa7'| nc -q 2 -4 -u 10.10.1.126 9

I can see it BOOTPing happily. (Amused it still identifies itself as a TIVA, could you guys not even change the ROM ID string when you lifted the code out :-)

Now, as I understand it if i have my normal DHCP server issue a BOOTP response with a boot file it will then pull that from the TFTP server and flash it's memory.

My first question is what format is the file in? Raw binary image or is it an intelligent format?

I know there is a bootloader tool, mspbsl, which can do this and it takes a .txt file eeprom image. However that tool has some amusing problems. (under Linux anyway)

  • On a multi NIC system it sends the broadcast magic packet, and BOOTP replies out the default routed port. Not so good when you have separate production and development environments and your BOOTP replies are going to the broadcast address of the wrong subnet...
  • As it tries to listen on the BOOTP ports, and do so across all interfaces, I have to shut down my DHCP server to use it. Again, a nightmare when you have production and development systems.

I fixed the first issue with NICs with a bit of very nasty boost coding, and rebuilding it from source. The second is rather more annoying, hence why I'd like to use the existing DHCP/TFTP system to deliver updates.

Second Question.

Does the Ethernet bootloader timeout? If sent into bootloader mode and it gets no BOOTP (or initial TFTP) reply does it abort and reboot? So if it never gets as far as doing any erasing/programming will it timeout or sit there for ever until power cycled?

Does it perform a full system reset (or just CPU reset) after flashing? I ask as my design seems to die during start up at this point, however a power cycle and it's fine. it also works if you do a System reset via the debugger. I am wondering if i need to reset some peripherals in my start up code that are not being reset. 

Cheers!

/\/\arc

  • 0
    TI__Guru**** 244440 points
    Hello Marc,

    The file format is TI TXT file format for using the BSLScripter. For more details on the BSL Scripter and Ethernet Firmware Upgrade please see the following SLA

    dev.ti.com/.../

    Parts of BOOTP has been superseded by DHCP as a more efficient method, but DHCP can still perform BOOTP functions.

    Currently the Ethernet Boot Loader does not timeout. Hence to be able to manage an auto-reset, a timer may be enabled to count for a predefined time. The timer shall be reset if it gets a BOOTP or TFTP packet. The right method to do so would be to flash the incoming TFTP packets to an unused section of the Flash. Once the final packet is received, it would flash the image from the unused section of Flash to the execution section of Flash and then jump to the image. This will allow the system a graceful method of recovery, in the event that the TFTP does not complete, since the original firmware has not been overwritten.
  • 0 in reply to Amit Ashara
    Prodigy 90 points

    Hi Amit,

    Thanks for the reply. I had hoped to get away with using the rom based bootloader but looking at the source code for the flash based one it seems a better way to proceed as it makes it a lot easier to tailor the upgrade system to something we could deploy with a central controller.

    Examining the bootloader code it looks like the TFTP data is just a raw binary dump of what to program into the flash. The translation from TI-TXT is all done in the BSLScripter. I am pretty sure we can convert the elf binary to a raw binary (or the output from the arm hex tool into a raw binary) and serve it with our existing tftp server systems. I am think about a tftp filename system similar to that used by PXE where it uses the UUID, then the MAC, the the IP and finally a default filename when checking what to boot. This will allow us to control what is installed on individual machines easily by just changing the tftp directory pointers. 

    I am hoping our application will be small enough to allow us to do the double buffering method you suggest too, with a CRC at the end to verify things, I believe it will be possible without too much hassle.

    Regards

    Marc.

  • 0 in reply to madphysics
    TI__Guru**** 244440 points
    Hello Marc

    You are right about the binary dump. The BSL Scripter does that internally. So technically you can use any output format as long as it can be converted to raw binary image. If image size is a concern, then I would suggest using an external Serial Flash or USB Flash (if sufficient pins are available) for retaining the copy of the newly downloaded firmware. It does complicate the boot loader, but works (I had tested one) very well for large sized images.

**Attention** This is a public forum