User Tools

Site Tools


manual:net_demo

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
manual:net_demo [2014/07/24 16:59]
voorburg [Notes]
manual:net_demo [2019/09/24 22:03] (current)
Line 2: Line 2:
  
 ===== Bootloader configuration ===== ===== Bootloader configuration =====
 +
 In order to perform firmware updates with the OpenBLT through a TCP/IP network, double-check that the network communication interface is configured in "​blt_conf.h"​. The following macro should have a value of 1. If this macro did not yet have a value of 1, the bootloader should be rebuild after making the change. In order to perform firmware updates with the OpenBLT through a TCP/IP network, double-check that the network communication interface is configured in "​blt_conf.h"​. The following macro should have a value of 1. If this macro did not yet have a value of 1, the bootloader should be rebuild after making the change.
 +
 <​code>​ <​code>​
 #define BOOT_COM_NET_ENABLE ​           (1) #define BOOT_COM_NET_ENABLE ​           (1)
 </​code>​ </​code>​
  
-===== Preparing Microboot ​===== +===== Using MicroBoot ​=====
-The Microboot utility needs to be configured to connect to the correct IP address and port:+
  
-  * Start Microboot by double-clicking "​\Host\**MicroBoot.exe**"​. +The MicroBoot ​utility needs to be configured to connect ​to the correct ​IP address and port:
-  * Click the "​**Settings**"​-button and select "​**OpenBLT using TCP/​IP**"​ from the dropdown box. +
-  * Click the "​**Options**"​-button ​to configure ​the communication parameters. +
-    * Set the hostname of your microcontroller system on the network. This is its IP-address, which is typically specified by the macro'​s BOOT_COM_NET_IPADDR in "​blt_conf.h"​. The default is **169.254.19.63** ​and will work if you have the system directly connected to your PC's ethernet port. +
-    * Set the port on which the bootloader listens for firmware update connection requests. This is specified by the macro BOOT_COM_NET_PORT in "​blt_conf.h"​. Typically, this is **1000** for the demo programs. +
-    * Check off the "​Automatically retry socket connections"​-checkbox if the system is directly connected to your PC's ethernet ​port.+
  
-Once you saved the settings ​by clicking the "**OK**"​-button ​twiceMicroboot ​is now ready for action!+  * Start MicroBoot ​by double-clicking ​"​\Host\**MicroBoot.exe**"​ (on Linux it is "​\Host\**MicroBoot**"​). 
 +  * Click the "**Settings**"​-button ​and select "**XCP on TCP/​IP**"​ from the "​Interface selection"​ dropdown box. 
 +  * Set the IP address (or fully qualified domain name) of your microcontroller system on the network.  
 +    * Most TCP/IP demo programs have DHCP support enabled (BOOT_COM_NET_DHCP_ENABLE set to 1) for automatic assignment of an IP address by your router. Log into your router'​s admin panel to determine which IP address was assigned. In case DHCP support is disabledthe IP address ​is specified by the macro'​s BOOT_COM_NET_IPADDRx in "​blt_conf.h"​. 
 +  * Set the port on which the bootloader listens ​for firmware update connection requests. This is specified by the macro BOOT_COM_NET_PORT in "​blt_conf.h"​. Typically, this is **1000** for the demo programs.
  
-===== Downloading ​the user program ===== +Once you saved the settings by clicking ​the "**OK**"​-button, ​MicroBoot ​is now ready for action!
-After building your user program, its S-record formatted firmware file can be downloaded to the remaining flash memory using the bootloader. In **Microboot** click the "**Browse**"​-button ​and select your user program'​s firmware file. For the demo programsthis one is located in the "​.\**Prog**\bin\"​ directory. Once the firmware file was selected, the download should automatically start. ​+
  
-{{:manual:demos:​olimex_stm32e407_net_download.gif?|}}+After building your user program, its S-record formatted firmware file can be downloaded to the remaining flash memory using the bootloader. In **MicroBoot** click the "​**Browse**"​-button and select your user program'​s firmware file. For the demo programs, this one is located in the "​.\**Prog**\bin\"​ directory. Once the firmware file was selected, the download should automatically start.  
 + 
 +{{:manual:ti_eklm3s6965_download_net.png?|}}
  
 Once the download completed, the newly programmed software will be started by the bootloader. For the demo program'​s you can verify this by checking that the LED blinks. Congratulations! That's all there is to using the bootloader. Once the download completed, the newly programmed software will be started by the bootloader. For the demo program'​s you can verify this by checking that the LED blinks. Congratulations! That's all there is to using the bootloader.
 +
 +===== Using BootCommander =====
 +
 +The BootCommander command line interface (CLI) program allows you to configure all communication settings via options on the command line. The following example demonstrates how to call BootCommander for making a firmware update with one of the demo programs. Just set the “**-a**” option to the IP address or hostname of the target to connect to and set the "​**-p**"​ option to the TCP port number that the target listens on..
 +
 +<​code>​
 +BootCommander -s=xcp -t=xcp_net -a=192.168.178.23 -p=1000 demoprog_ek_lm3s6965.srec
 +</​code>​
 +
 +The example assumes that the S-record of the demo user program is located in the same directory as where the BootCommander executable itself resides. If not, then simply prepend the absolute (or relative) directory to the name of the S-record firmware file.
 +
 +===== Timeout configuration =====
 +
 +The default timeouts of the XCP communication protocol work fine in case the ping time between your PC host and microcontroller is not more than 30 milliseconds. This is for example the case when your microcontroller is connected to a local network.
 +
 +When the ping time between your PC host (or remote server) and microcontroller is more than 30 milliseconds,​ a reconfiguration of the XCP timeouts (T1, T3, T4, T5, T6 and T7) is needed. It is recommended to add 1.5 times the average ping time to the default values of the XCP timeouts.
 +
 +For example, when testing firmware updates from a Debian server in Tokyo (running BootCommander) to a microcontroller connected to a router in Germany, the ping time was about 250 ms. The XCP timeouts were incremented by 375 ms to compensate for this network latency:
 +
 +^ Timeout ^ Default value [ms] ^ Reconfigured value [ms] ^
 +| T1 | 1000 | 1375 |
 +| T3 | 2000 | 2375 |
 +| T4 | 10000 | 10375 |
 +| T5 | 1000 | 1375 |
 +| T6 | 50 | 425 |
 +| T7 | 2000 | 2375 |
 +
 +These timeouts can be configured on MicroBoot’s settings dialog or using command-line options in BootCommander:​
 +
 +{{:​manual:​xcp_timeout_configuration.png |}}
  
 ===== Notes ===== ===== Notes =====
-Depending on the hardware in your network, you might have to change the option "​Automatically retry socket connections"​ in the Microboot settings for the bootloader'​s backdoor to work properly. ​ 
-{{:​manual:​demos:​socket_retry_option.gif?​|}} 
-\\ 
-Testing indicated that this option should be **enabled** when your microcontroller system is directly connected to your PC's ethernet port. However, if you system is connected to a router in the network, this option should be **disabled**. Feel free to experiment with this settings in case firmware updates don't seem to work. 
  
-Depending on the configuration ​of the bootloader, ​there might be a delay between a system ​reset and the actual start of the user program. ​This is needed by design for the bootloader'​s backdoor ​functionality. ​Check configurable BACKDOOR_ENTRY_TIMEOUT_MS ​in "blt_conf.h" for the exact delay timeNote that this delay is configured relatively long (several seconds) for the TCP/​IP ​demo programs. This is because it can take quite some time after the bootloader ​got re-activated for the system to become responsive on the networkFeel free to fine-tune this value to your needsBasicallyreset your system and measure how much time is needed for it to respond to PING-requests.+The initialization ​of the TCP/IP network stack, up to the point where the bootloader ​can accept firmware update requestscan take several seconds. This delay occurs after each reset event, before your user program ​is startedBecause such a long delay is typically not desired, ​the demo programs have the so called deferred initialization ​functionality ​enabledThis was done via configuration macro BOOT_COM_NET_DEFERRED_INIT_ENABLE ​in blt_conf.h. 
 + 
 +With the deferred initialization enabled, the TCP/IP stack initialization ​is skipped during a normal reset event, unless: [a] there is no valid user program present, or [b] the bootloader was forced to stay active. This latter case happens when the CpuUserProgramStartHook()-function is enabled and returns BLT_FALSE. 
 + 
 +To be able to perform remote firmware updates without having to access the system, a third scenario [c] was added in the demo programs ​for forcing ​the TCP/​IP ​stack to be initialized. This is the case when the bootloader ​was started from the user programThe [[https://​www.feaser.com/​en/​blog/?​p=216|shared parameter module]] was integrated into both the demo bootloader and user program, ​to be able to pass information from the user program to the bootloaderAfter the user program detects a firmware update request from the TCP/IP network, it sets a shared parameter in RAM right before the bootloader is activated. Upon activation, the bootloader evaluates this shared parameter and initializes the TCP/IP stack when requested. 
 + 
manual/net_demo.1406213976.txt.gz · Last modified: 2019/09/24 22:07 (external edit)