MSPBSL: BSL Scripter with Ethernet not working

Hello Charles

Charles Tsai said:

Are you running the bootloader example on the LaunchPad or your own custom board? Have you tried running on the LaunchPad and what is the result?

Yes I'm running the same bootloader and application mentioned in the resource explorer following the same steps as mentioned there. The results i shared were from the launchpad only. I have not tried in my custom board yet.

  IPClient=192.168.254.4 IPServer=192.168.254.3 is also unused and the MAC Address 70:FF:76:1C:E0:B9 is the one pasted behind the launchpad and i also read the same with UNIFLASH. So this is also fine.

Charles Tsai said:

I strongly suggest your run the ready to use example, shown below again.

As you have mentioned, I first erased the flash with Uniflash and then tried the example in C:\ti\BSL-Scripter\ScriptExampleWindows\E4xx_ethernet. The script 1 itself is not successful.

Since there is no bootloader in the launchpad right now, i couldn't see any frames in the wireshark.

Can you please guide us further to debug this?

I also have a question, when there is no ethernet related bootloader flashed in the MCU before running script_1.txt, how will the MCU send BOOTP request?

Mp said:

  IPClient=192.168.254.4 IPServer=192.168.254.3 is also unused and the MAC Address 70:FF:76:1C:E0:B9 is the one pasted behind the launchpad and i also read the same with UNIFLASH. So this is also fine.

I have a question with your above statement. Do you mean that IPServer=192.168.254.3 is also an unused address? IPSever is supposed to be the address for your PC running the BSL Scripter. It must be a valid IP that is assigned to your PC. You can use ipconfig to find out its IP address. See below example. If your ipconfig shows that the NIC on your PC is assigned with 192.168.254.3, then that is fine. 

Mp said:

Since there is no bootloader in the launchpad right now, i couldn't see any frames in the wireshark.

Can you confirm the flash is indeed fully erased? You can do a blank check to see if the flash is empty. The purpose of script 1 is to download the custom flash-based bootloader to the MCU using MCU's ROM-based bootloader. In another word, when the flash is empty, the ROM memory on the device has the bootloader that will be called to first download a custom flash-based bootloader to the flash at 0x0.   

Once the flash-based bootloader is downloaded, you can check for its presence at 0x0. Do you see it? Once the flash-based bootloader is downloaded, it will start to run. The ROM-based bootloader will no longer be called as the device knows that there is a valid program image at 0x0 by checking for a valid SP and Reset vector at 0x0 and 0x4. You will then run Script 2 so that the flash-based bootloader will download the application firmware. 

Mp said:

Can you please guide us further to debug this?

You can also directly use JTAG to first the flash-base bootloader just like loading any program like the blinky or hello. The Script 1 is meant to demonstrate that you can use the built-in ROM bootloader to download a program instead of using JTAG but the flash must be fully erased first. 

Mp said:

I also have a question, when there is no ethernet related bootloader flashed in the MCU before running script_1.txt, how will the MCU send BOOTP request?

I have explained above for the ROM-based bootloader when the device's flash is fully erased.

I just wanted to let you know that I run the same example and it is working for me on the LaunchPad. See below. 

1. I first erase the flash.

2. I run script 1 and the below log is showing successful download of the custom bootloader. 

After I successfully run Script 1, I reset the board and wait for BOOTP request to show up on Wireshark before I run Script 2 and I don't have a problem. 

Hello Charles,

Charles Tsai said:

You can use ipconfig to find out its IP address.

I'm using the ip mentioned below as IPServer=192.168.254.3.

Charles Tsai said:

Can you confirm the flash is indeed fully erased? You can do a blank check to see if the flash is empty

Blank check was also done, the flash is blank.

I understood your points, so now the ROM bootloader itself has the provision to send bootp request. But in the launchpad, no bootp request was seen in wireshark even after blank check.

So i did a unlock sequence to bring the mcu in factory reset state. then i could see bootp request in wireshark with the default MAC(00:1A:B6:00:64:00) set in the ROM Bootloader. With this MAC itself, i tried running script_1 but it was waiting for bootp and failed. And then with UNIFLASH i programmed the MAC with the one pasted at the back of launchpad(70:FF:76:1C:E0:B9). after which i tried to run the script, still in the same state.

I made a power reset while running the script then it worked till TFTP as below screenshot

Charles Tsai said:

You can also directly use JTAG to first the flash-base bootloader just like loading any program like the blinky or hello

After the above changes, i tried to flash the custom flash bootloader to the launchpad with UNIFLASH and then did a power reset and then ran the script_2, but it failed the same way as Invalid TFTP request received. But this doesn't require a power reset while running the script_2.

I have also modified the firewall to allow all ports in both inbound and outbound rules, please verify in the below image, if something is still required to be done in firewall.

Thanks in advance.

Mp said:

I'm using the ip mentioned below as IPServer=192.168.254.3.

In this image, it looks like you have two NIC. One at 10.169.227.26 and another at 192.168.254.3. Can you disable the NIC at 10.169.227.26. Only keep the NIC at 192.168.254.3 that are on the same network at the Client. This will be the first experiment I'd suggest you do. 

The next experiment would be to disable the NIC at 192.168.254.3 and use the NIC at 10.169.227.26. You will need to first find out which unused IP address the MCU can use. You can first run a simple ethernet_lwip example to find out the DHCP address. It will be something like 10.109.xxx.yyy. Record this address and use that address as your IPClient in the script file. 

I have run the out of box examples as-is on the LaunchPad with success. This means the examples should work. It is very likely a problem with either your network or your NIC. Try the above two experiments and let me know what is the result. Maybe you can try another PC. Have you tried on another network, for example your home network?

Mp said:

I understood your points, so now the ROM bootloader itself has the provision to send bootp request. But in the launchpad, no bootp request was seen in wireshark even after blank check.

It is very likely that the BOOTP request is not seen by the NIC at 192.168.254.3 but rather by the NIC at 10.169.227.26. Why don't you use wireshark to look at traffics for the NIC "Ethernet adapter Ethernet" shown on your ipconfig?

Hello Charles,

I connected 192.168.254.3 and didnt connect 10.169.227.26(office LAN). It got flashed as expected. But the problem is i have to reset the MCU everytime i run the script. If i dont reset it, its waiting for BOOTP and completing with error as No Bootp request received.

Only when the office LAN is connected, it is stopping with a error as invalid TFTP read request.

Charles Tsai said:

You can first run a simple ethernet_lwip example to find out the DHCP address.

I tried to check for the DHCP IP with the magic packet firmware flashed with the script and with the enet_lwip example i'm getting a DHCP IP as below

But i think this ip is an invalid DHCP while searching it was mentioned that "A 169.254 IP address is called an APIPA IP address. Your computer receives a 169 APIPA address when it can’t get an address from the DHCP server " Please correct me if i'm wrong.

I tried running the same example in my colleagues PC as well, it was also having 169.254.186.x

Then I erased flash and tried flashing the script_1 with custom bootloader and script_2 with blinky code available in resource explorer. The flashing was completed successfully but no blinking happened. Why is that so?

Also can you please tell how to reflash the MCU via ethernet? Is it like everytime we want to flash the new firmware we should go from erasing the flash, script1 and script2. or anyother way possible?

Everything i've tried above, i did in both custom board and in launchpad,both gave same outputs as i've mentioned above.

Thank you!

Mp said:

I connected 192.168.254.3 and didnt connect 10.169.227.26(office LAN). It got flashed as expected. But the problem is i have to reset the MCU everytime i run the script. If i dont reset it, its waiting for BOOTP and completing with error as No Bootp request received.

In this image, it looks like it finally works for you. If you refer to the user's guide for running the bootloader, it says to reset the board after the download. see https://dev.ti.com/tirex/explore/node?fullTextSearch=Static%20Ip%20&fullTextSearchPage=1&node=A__ADn.VTNH8qUYxgak.wnmVw__com.ti.SIMPLELINK_ACADEMY_MSP432E4SDK__Nh7md.m__LATEST

Mp said:

I tried to check for the DHCP IP with the magic packet firmware flashed with the script and with the enet_lwip example i'm getting a DHCP IP as below

If you are getting 169.254 then it means there is no DHCP server on the network on which the MCU and 192.168.254.3 are connected. You need to check with IT department if there is a DHCP server on the subnet starting with 192.168.

Why don't you try disabling the NIC at 192.168.254.3 and use 10.169.227.26(office LAN) instead? What do you get?

Mp said:

Then I erased flash and tried flashing the script_1 with custom bootloader and script_2 with blinky code available in resource explorer. The flashing was completed successfully but no blinking happened. Why is that so?

Did you reset the board? Does it blink? Please also note that your blinky program must start at 0x0. You can NOT just use a regular blinky program that starts at 0x0. You must rebuild the blinky program to start at 0x4000. 

Mp said:

Also can you please tell how to reflash the MCU via ethernet? Is it like everytime we want to flash the new firmware we should go from erasing the flash, script1 and script2. or anyother way possible?

You must build you own application so that it will listen to a magic packet and then jump back to the bootloader to start a new firmware update. Refer to the magicpacket example for reference. This example firmware shows how to receive a magic packet and then jumps back to the bootloader when your BOOTP sever sends a magic packet to the board. 

Charles Tsai said:

Did you reset the board? Does it blink? Please also note that your blinky program must start at 0x0. You can NOT just use a regular blinky program that starts at 0x0. You must rebuild the blinky program to start at 0x4000. 

Yeah i did a reset but still it didn't blink

Yeah may be it would not start at 0x0..

Can you please tell how to change the starting address of a code?

If you refer to boot_emac_flash_app_magicpacket_update example at C:\ti\simplelink_msp432e4_sdk_4_20_00_12\examples\nortos\MSP_EXP432E401Y\boot_loader\boot_emac_flash_app_magicpacket_update\ccs you will find the .cmd file. It is simply just changing the APP_BASE to -0x4000 from 0x0. Use this .cmd file on your blinky example and rebuild it. 

#define APP_BASE 0x00004000

MEMORY
{
    FLASH (RX) : origin = APP_BASE, length = 0x000FC000
    SRAM (RWX) : origin = 0x20000000, length = 0x00040000
}

/* The following command line options are set as part of the CCS project.    */
/* If you are building using the command line, or for some reason want to    */
/* define them here, you can uncomment and modify these lines as needed.     */
/* If you are using CCS for building, it is probably better to make any such */
/* modifications in your CCS project and leave this file alone.              */
/*                                                                           */
/* --heap_size=0                                                             */
/* --stack_size=256                                                          */
/* --library=rtsv7M4_T_le_eabi.lib                                           */

/* Section allocation in memory */

SECTIONS
{
    .intvecs:   > APP_BASE
    .text   :   > FLASH
    .const  :   > FLASH
    .cinit  :   > FLASH
    .pinit  :   > FLASH
    .init_array : > FLASH

    .vtable :   > 0x20000000
    .data   :   > SRAM
    .bss    :   > SRAM
    .sysmem :   > SRAM
    .stack  :   > SRAM
}

__STACK_TOP = __stack + 512;

Hello Charles,

Thanks, the blinky code worked with the above modification.

I integrated the magic packet code in my existing code as below and tried flashing the same. my existing functionalities worked fine but when i flashed the blinky code it got flashed completely but didn't blink. The address is proper as well. This i tried in both launchpad and custom board it is getting flashed but not blinking.

The same blinky code i tried flashing with TI resource explorer magic packet code, it worked fine. I'm not sure what's wrong here. Can you please tell if i have missed something in the code.

void SoftwareUpdateRequestCallback(void)
{
    g_bFirmwareUpdate = true;
}
/* Perform the initialization steps required to start up the Ethernet controller
 * and lwIP stack. */
void
SetupForEthernet(void)
{
    /* Start the remote software update module. */
    SoftwareUpdateInit(SoftwareUpdateRequestCallback);
}

int main()

{

  uint32_t ui32User0, ui32User1;

  SysCtlMOSCConfigSet(SYSCTL_MOSC_HIGHFREQ);

    //
    // Run from the PLL at 120 MHz.
    //
    g_ui32SysClock = MAP_SysCtlClockFreqSet((SYSCTL_XTAL_25MHZ |
                                             SYSCTL_OSC_MAIN |
                                             SYSCTL_USE_PLL |
                                             SYSCTL_CFG_VCO_480), 120000000);

  PinoutSet(true, false);

 UARTStdioConfig(0, 115200, g_ui32SysClock);

  MAP_SysTickPeriodSet(g_ui32SysClock / SYSTICKHZ);
    MAP_SysTickEnable();
    MAP_SysTickIntEnable();

 MAP_FlashUserGet(&ui32User0, &ui32User1);
    //
    // Convert the 24/24 split MAC address from NV ram into a 32/16 split MAC
    // address needed to program the hardware registers, then program the MAC
    // address into the Ethernet Controller registers.
    //
    pui8MACArray[0] = ((ui32User0 >>  0) & 0xff);
    pui8MACArray[1] = ((ui32User0 >>  8) & 0xff);
    pui8MACArray[2] = ((ui32User0 >> 16) & 0xff);
    pui8MACArray[3] = ((ui32User1 >>  0) & 0xff);
    pui8MACArray[4] = ((ui32User1 >>  8) & 0xff);
    pui8MACArray[5] = ((ui32User1 >> 16) & 0xff);

SrcIPaddr.addr = htonl(inet_addr(sourcIP));

      lwIPInit(g_ui32SysClock, pui8MACArray,SrcIPaddr.addr, NETMASK, GWADDR, IPADDR_USE_STATIC);
      UdpClientInit();
      /* Setup the call back function for magic packet detect on UDP Port 9 */
         SetupForEthernet();

 MAP_IntPrioritySet(INT_EMAC0, ETHERNET_INT_PRIORITY);
    MAP_IntPrioritySet(FAULT_SYSTICK, SYSTICK_INT_PRIORITY);


    while(1)
    {
        if(g_bFirmwareUpdate == true)
        {
            SoftwareUpdateBegin(g_ui32SysClock);
            return(0);
        }
    }

Thank you.

Mp said:

I integrated the magic packet code in my existing code as below and tried flashing the same. my existing functionalities worked fine but when i flashed the blinky code it got flashed completely but didn't blink. The address is proper as well. This i tried in both launchpad and custom board it is getting flashed but not blinking.

When you press the reset button, does the board blink?

Can you check if your bootloader is still at 0x0? Use the Memory Browser to view the flash content at 0x0.

You can do some debugging on your own by placing breakpoints in the main() and single step the code to understand if the bootloader jumps to the application. If the application is jumped to at 0x4000, then single step to find out why the LED is not blinking. Once the blinky binary file is loaded, in CCS, you can use 'Load Symbols' so you can debug the code by placing breakpoints. 

Charles Tsai said:

When you press the reset button, does the board blink

Yes even after reset it didnt blink.

Tried flashing my application code with magic packet with CCS, placed breakpoints and checked if it is getting the magic packet and proceeding further to the softwareupdate function which jumps to the bootloader. It went till there and then i terminated.

Since the address was at 0x4000 it didnt work while flahsing with ccs only after changing the address to 0x0 it worked in ccs.

So i can flash these code via BSL scripter and parallely check with load symbols in the CCS. Please correct me if my understanding here is wrong.

Charles Tsai said:

. If the application is jumped to at 0x4000, then single step to find out why the LED is not blinkin

In the blinky application code, i have modified the Flash start address to 0x4000 in the cmd file. Is there anything other than this to be done in anyother file/the magicpacket project?

Mp said:

Tried flashing my application code with magic packet with CCS, placed breakpoints and checked if it is getting the magic packet and proceeding further to the softwareupdate function which jumps to the bootloader. It went till there and then i terminated.

What do you mean by terminated? You didn't answer me if you have the bootloader still in place at 0x0. Why don't you show me the Memory Browser contents at 0x0?

If you want to load both the bootloader (at 0x0) and the application (at 0x4000) at the same time using JTAG you can use Uniflash.