MSP432E401Y: Update over ethernet

When I tried this myself using a Launchpad board, over a year ago, I made myself the following note:

Connect host pc, target board and DHCP server to a switch.

This seems quite important. Without the switch, if BOOTP packets go via the router/dhcp server, it seems to interfere with the BOOTP requests.

Could this be relevant to you?

I then noted:

Load magic packet demo app.
Set script2.txt to have MAC of target board and an unused IP address, and IP address of host PC.

Reset target board which will now boot into the Flash bootloader.

At PC command prompt, run
BSL-Scripter.exe script_2.txt
Should see:-

And I got:

...
Client IP address: 192.168.0.43
TFTP read request received!
Get the port of TFTP request endpoint: 3541
RX_DATA_BLOCK_32 boot_emac_flash_app_magicpacket_update_MSP_EXP432E401Y_nortos_ccs.txt
Read Txt File : c:\Sandbox\BSLScripter\MyTest\home\boot_emac_flash_app_magicpacket_update_MSP_EXP432E401Y_nortos_ccs.txt
Time elapsed of writing 48008 bytes : 1.078 seconds
Speed of writing data :43.49(kB/s)

Does this help?

I am able to receive BOOTP request and load script_1.txt and script_2.txt. After loading script_2.txt (aka magic packet update app) I am not able to load my blink code. I've backtracked the problem and found out that the length of the packets I am sending is 18 while the program waits 30. 

Which does not satisfies the if condition in swupdate.c file and drops the packets.

Idk how but I will try to match the sizes

Hi,

It seems odd that the BSL scripter prog would send the correct size packets for one text file, but not for another - perhaps there is another problem!

Looking back at my notes from when I first tried this, I find:

Note, the zip script 3 tries to load a new project ../blink_app2_MSP-EXP432E401Y.txt which is not present in the zip. I replaced that text with the same magicpacket app, to show it would go round the full cycle.

Does this mean that you had to build your own version of "Blink"? Could there be a problem with it? Does the linker command file shift it to live at address 0x4000, after the bootloader?

Just some thoughts!

Jim

Hi Jim,

Thanks for the reply however I am still stuck at the same problem. Here are the steps that I am following, is there something wrong with my process?

 1. Erase the main flash 

 2. Run BSL with scrip_1.txt (Sends bootloader)

 3. Run BSL with script_2.txt (Sends magic packet update)

 4. Run BSL with script_3.txt (Sends the blink app that I've wrote)

In 4th step BSL scripter stucks at "waiting for bootp" and when I try to send the package with TFTP command package size is 18 rather than 30 thus app drops the packages. 

And yes linker shifts is to 0x4000. 

That's odd - it all looks OK.

Can you do step 3 twice, so replace the magic packet update app with itself. That should help determine if the problem is with your blink application or with the update process.

It was over a year ago now, but I did pretty much what you have done and it seemed to work.

Still the same problem :( . I am able to send magic packet update code first time around but cannot pass "waiting for bootp request" when I try to send it second time.

This image is from second attempt.

Hi,

boot_emac_flash_app_magicpacket_update_MSP_EXP432E401Y_nortos_ccs.txt is an application. This application is supposed to wait for a magic packet from the BSL which is trying to send your blinky.txt. When the application receives the magic packet, it will transfer the control to the flash bootloader. The flash bootloader will then send the BootP request. If BootP request is not received then it could mean that the magic packet was never received by the client or the client for some reason did not transfer the control to the bootloader. 

Do you see the magic packet when you try to send the blinky.txt when you execute script_3.txt?The magic packet should  comprises 6 bytes of 0xAA followed by the target MAC address repeated 4 times. Is it possible that BSL send the magic pack to a wrong NIC? I have seen for a different device (e.g. TM4C129) that magic packet is sent to a different NIC. If your PC has multiple NICs then disable all of them except the one that is used to communicate with the client (the MSP432E MCU). 

  If you have seen the magic packet sent to the client but the client did not jump to the bootloader then you will need to somehow debug why it didn't do so. The source code for the application is in C:\ti\simplelink_msp432e4_sdk_4_20_00_12\examples\nortos\MSP_EXP432E401Y\boot_loader\boot_emac_flash_app_magicpacket_update\enet_lwip.c.

  As you can see, the application is waiting for g_bFirmwareUpdate to set. g_bFirmwareUpdate is only set when the magic packet is received. Upon receiving the magic, it will transfer control to the bootloader by calling SoftwareUpdateBegin(). 

Below is the snippet of code. 

I want to also give you a heads-up. I will be on vacation until Jan-3 and unable to respond during my absence. 

/* This function is called by the software update module whenever a remote
* host requests to update the firmware on this board. We set a flag that
* will cause the main loop to exit and transfer control to the bootloader.
*
* IMPORTANT:
* Note that this callback is made in interrupt context and, since it is not
* permitted to transfer control to the boot loader from within an interrupt,
* we can't just call SoftwareUpdateBegin() here. */
void SoftwareUpdateRequestCallback(void)
{
g_bFirmwareUpdate = true;
}

snipped....

/* If the firmware request is not issued by the Host then blink the LED D1
* On switch firmwar request detect exit the blinking program and jump to
* the flash boot loader. */
while(!g_bFirmwareUpdate)
{
MAP_GPIOPinWrite(GPIO_PORTN_BASE, GPIO_PIN_1, 0x0);
MAP_SysCtlDelay(getSystemClock / 6);
MAP_GPIOPinWrite(GPIO_PORTN_BASE, GPIO_PIN_1, GPIO_PIN_1);
MAP_SysCtlDelay(getSystemClock / 6);
}

/* Before passing control make sure that the LED is turned OFF. */
GPIOPinWrite(GPIO_PORTN_BASE, GPIO_PIN_1, 0x0);

/* Pass control to whichever flavour of boot loader the board is configured
* with. */
SoftwareUpdateBegin(getSystemClock);

Thanks for the reply. After fooling around a bit I was able to send "blink.txt". I created a UDP client that sends a magic packet and then initialize BSL steps. However after uploading the code it does not run the application. The code is working since when I program MSP via JTAG it runs without a problem but with BSL it does not. I try to shift the code to @4000 and other locations like @6000 etc. Any ideas why the code does not work?

Hi,

  Sorry, I just got back from vacation.

  Can you check if your flash bootloader is in the flash at 0x0? In script_1.txt, it is supposed to program the boot_serial_emac_flash_MSP_EXP432E401Y_nortos_ccs.txt to the flash the 0x0. Please make sure when you download the blink.txt, the flash bootloader boot_serial_emac_flash_MSP_EXP432E401Y_nortos_ccs.txt did not erase itself. You can open the CCS memory browser and check if there is any code at 0x0. The reason I ask to check this is because after reset the flash bootloader will first check if there is a valid stack pointer and reset vector at location 0x0 and 0x4. If it finds valid stack pointer and reset vector at these two addresses then it will jump to the application which is your blinky.txt and start running. If these two locations are somehow erased then it will enter bootloading mode again. 

  Please also refer to this app note for MSP432E4 BSL. https://www.ti.com/lit/slau746

  The source code for the flash bootloader can be found in C:\ti\simplelink_msp432e4_sdk_4_20_00_12\source\ti\devices\msp432e4\boot_loader.