Downloading using Setr and itl

https//www.racom.eu/eng/support/download/down-itl.html

Print version

4. Downloading using Setr and itl

The downloading of firmware over the radio channel is a relatively complicated task containing various dangers for the network. This is why it is only recommended for experienced operators.

The downloading mentioned here allows for the transfer of firmware modules between Communication units (CU) in the MORSE network. It uses the itl service of the SETR program, which allows both ways of loading the firmware module into the CU:

  • via D-RAM memory for MR400, see article 1. and 2.

  • directly into Flash memory for MR25, see article 3. and 4.

4.1. Downloading the main module E using the kernel module into MR400

These conditions must be accomplished:

  • good connection between the source and destination CU via some MORSE channel (radio, ethernet, SCC), in case of the radiochannel a direct connection without retranslation is recommended

  • the destination CU contains the D-RAM, so it is the MR400, MR160, MR900, MC100 (but not MR25)

  • the source CU contains this main module (E or D or …), which should be transfered in the destination CU

In program Setr.exe the menu memload is filed amongst tests. Open using command itl and fill in the following items:

(N):1

choice of the node for communication with the destination CU

(d):690F0002

address of destination CU

(x):4

number of 128 byte sectors transferred in one packet, for wrong conditions of the radio connection choose the lower number, e.g. x=2, for very good conditions use x=8

(m):m

module mode

(y):k

module type kernel, the choice is indicated by the address pair
01000001, 03000001 on the next row

Memload: 
(N):1   (d):690F0002h
(E)xternal flash:OFF
ma(x) sectors:4   (m)odule:MODULE   preset t(y)pe
User module: fi(r)st:01000001   (l)ast:03000001  
(t)imeout:12000
(s)tart r(e)port sto(p)
go MORSE (A)/(W)
(i)nit
(f)ire (k)ill (c)ontinue
check through (S)UM32
go MORSE (B)
(C)..modprobe with chksum
(M)odprobe
(q)uit
>>

Continue with next commands:

(s) Enter

start test itl

(i) Enter

init in the destination CU

(e) Enter

report – check the test report before work:

This is Memload v1.03 response
max. MF sectors per packet :4
loading module:  -
target        : 690F0002h
status :ready; Check result: none
begin  :FF040000h
end    :FF0FA580h
current:FF040000h
talking to MORSE E
timeout 12000
Time elapsed: 0msec
Transfer rate: -1.#IND00kbps
>>

The transfer starts using (f)ire and follow the progress using r(e)port:

(f) Enter

start transmission, LED indicate intensive operation on the RF channel

(e) Enter

report about the transfer progress:

...
status :waiting for memfill response; Check result: none
begin  :FF040000h
end    :FF0FA580h
current:FF053600h
...

The address current increases from address begin to the address end. If necessary, we can interrupt the process using (k)ill and go on using (c)ontinue. Transmission of the main module takes 10 to 15 minutes depending on network conditions at the time.

There is no special message indicating the end of transmission. However, we recognise that transmission has ended when the LED for RF transmission and receipt stops flashing. Definite information is contained in the reply to a r(e)port query, where address current has reached or exceeded address end:

status :all sectors are transfered.; Check result: none
begin  :FF040000h
end    :FF0FA580h
current:FF0FA580h
(C) Enter

the transferred kernel in the destination CU is checked and copied from D-RAM to the permanent memory S-RAM. It takes about 6 seconds.

(e) Enter

report:

status :pal O.K.; Check result: none
(p) Enter

stop test itl in the source CU

Downloading of the firmware module is completed.

The summary of commands used for MR400, main module, follows:

itl
  N1 d690F0002 x4
  mm      ... module mode
  yk      ... module kernel
  s i e   ... test start
  f e     ... loading
  C e     ... copy to S-RAM
  p       ... stop test

Module B-saver can be transferred similarly, like kernel module:

itl
  N1 d690F0002 x4
  mm      ... module mode
  ys      ... module saver ... different choice from kernel
  s i e   ... test start
  f e     ... loading
  C e     ... copy to S-RAM
  p       ... stop test

When transferring B-saver we receive a different message in the identification of modules 01000004, 03000004:

Memload: 
(N):1   (d):690F0002h
(E)xternal flash:OFF
ma(x) sectors:4   (m)odule:MODULE   preset t(y)pe
User module: fi(r)st:01000004   (l)ast:03000004

The range of transferred addresses is smaler:

begin  :FF030000h
end    :FF037400h
current:FF030000h

Transmission of the B-saver module takes about 30 sec.

4.2. Downloading the main module E using the loader and kernel module into MR25ET

These conditions must be accomplished:

  • good connection between the source and destination CU

  • the destination CU contains the D-RAM, so it is the MR25ET or MCM302 (but not MR25)

  • the source CU contains this main module (E or D or …), which should be transfered in the destination CU

  • the source CU contains the loader module mc10.fkl, best newly loaded using the command
    memcp -af./fkl/mc10.fkl -as8 -pb115200

The procedure is the same as in the previous case. The difference is that first we transfer a small module loader, select (y):l,and then we repeat the whole process for the main module (y):k. The module loader is identified by letter C, for example C757 is in the reply to an sv command. An overview of Setr commands used is given below :

itl
  N1 d690F0002 x4
  mm      ... module mode

  yl      ... module loader
  s i e   ... test start
  f e     ... loading
  C e     ... copy to S-RAM
  p       ... stop test

  yk      ... module kernel
  s i e   ... test start
  f e     ... loading
  C e     ... copy to S-RAM
  p       ... stop test

Module B-saver can be possibly transferred also:

  ys      ... module saver
  s i e   ... test start
  f e     ... loading
  C e     ... copy to S-RAM
  p       ... stop test

4.3. Downloading of module A or W or B through module E into MR25

These conditions must be accomplished:

  • good connection between the source and destination CU

  • the destination CU is MR25

  • the destination CU is MR25ET or MCM302 – the alternative method to the above mentioned one

  • the source CU contains this module (A or W), which should be transferred to the destination CU

The procedure is the same as in the previous cases, differences are outlined below:

itl

memload test in Setr

(d):690F8100

address of destination CU

(x):4

number of 128 byte sectors transferred in one packet

(m):A

module transferred, A represents both A or W

(s) Enter

start test itl

(i) Enter

init in the destination CU

(e) Enter

report – check the test report before work:

This is Memload v1.03 response
max. MF sectors per packet :4
loading module: MORSE A
target        : 690F8100h
status :ready Check result: none
begin  :  374000h
end    :  37D800h
current:  374000h
talking to MORSE E
timeout 12000
Time elapsed: 0msec
Transfer rate: nankbps

where is:

 loading module: MORSE A - modul A(= A or W) will be transferred
 talking to MORSE E      - the transfer will be done using module E (E or D or ...)
(f) Enter

start transmission

(e) Enter

report about the transfer progress

When completed, the report looks like this:

status :all sectors are transfered. Check result: none
begin  :  374000h
end    :  37D800h
current:  37D800h
(S) Enter

a checksum of the transferred module

(e) Enter

the previous message appears, however containing the row:

status :all sectors are transfered. Check result: O.K.

In the case, when the Check result is not O.K., stop the test and start again using the command (s)tart, see previous article.

(p) Enter

stop test itl in the source CU

Downloading of the firmware module is completed.

The summary of used commands follows:

itl
  N1 d690F8100 x4
  mA      ... module transferred
  s i e   ... test start
  f e     ... loading
  C e     ... copy to S-RAM
  p       ... stop test

4.4. Downloading of module E or B through module A or W into MR25

These conditions must be accomplished:

  • good connection between the source and destination CU

  • the destination CU is MR25 or
    the destination CU is MR25ET or MCM302 – the alternative method to the above mentioned one

  • the source CU contains this module (D, E…), which should be transferred to the destination CU

  • the destination CU contains module A, if we are going to transfer the main module on air, or
    the destination CU contains module W, if we are going to transfer the main module via wire link

Procedure:

itl

memload test in Setr

(d):690F8100

address of destination CU

(x):4

number of 128 byte sectors transferred in one packet

(m):E

module transferred, E represents the current main module in the source CU (E, D, G, H, I), B is the base module (B-saver)

(s) Enter

start test itl

(i) Enter

init in the destination CU

(A) Enter

switch the dest. CU in the module A

or

(W) Enter

switch the dest. CU in the module W in case of downloading via wire

(i) Enter

init in the destination CU

(e) Enter

report – check the test report before work

Sometimes it happens that a similar message appears:

status :ready Check result: none
begin  :  308000h
end    :  36A400h
current:  308000h
                   E via E???
talking to MORSE E

In this case switching from E to A module in the destination modem did not happen and we will repeat the commands:

(A) Enter

switch the dest. CU in the module A

(i) Enter

init in the destination CU

(e) Enter

check report

The right answer looks like this:

status :ready Check result: none
begin  :  308000h
end    :  36A400h
current:  308000h
talking to MORSE A(W)

where:

  talking to MORSE A(W)   - the transfer will be done using module A or W
(f) Enter

start transmission

(e) Enter

report about the transfer progress

When completed, the report looks like this:

status :all sectors are transfered. Check result: none
(S) Enter

a checksum of the transferred module

(e) Enter

the message contains the row:

status :all sectors are transfered. Check result: O.K.

The destination CU runs in module A or W. In this state (when downloading and after it has finished) the CU is able to perform routing and only certain commands. The short reply A602 follows an sv query and after query:

(N)ode (e)dit Enter

the message appears:

690F8100h> @  A/W: Service not available!

So after downloading has finished it is necessary to switch the destination CU in the main module again:

(B) Enter

switching the destination CU in B module

(i) Enter

restart of the destination CU is executed, the CU later goes into the main module

(e) Enter

checking if the destination CU is switched back into E module:

This is Memload v1.03 response
max. MF sectors per packet :4
loading module: MORSE E
target        : 690F8100h
status :ready; Check result: none
begin  :  308000h
end    :  36A400h
current:  308000h
                         E via E???
talking to MORSE E
timeout 12000
Time elapsed: 901158msec
Transfer rate: 0.000000kbps

If this message appears, then the destination CU is O.K. and we can stop the test:

(p) Enter

stop the memload test in the source CU

Downloading of the main module is finished.

The summary of commands used follows:

itl
  N1 d690F8100 x4
  mE      ... module transferred
  s i     ... test start
  A i e   ... switching dest CU in A module
  f e     ... loading
  S e     ... check sum
  B i e   ... switching through B into E
  p       ... stop test

If the basic module B is transferred in this way it is important not to interrupt operation on the destination CU until transmission is correctly finished. This means not restarting, switching off the power supply or using command go MORSE (B). After restarting the CU module B is started and if this module has not been fully transferred then the program doesn’t work. It is then necessary to complete or retransmit B whilst the CU is still in the auxiliary module A or W.

[Note]Note

All operations can be done using remote access. In this way it is possible to download the firmware module step by step in the whole network.

When the main module is downloaded via module A, then the destination CU can fulfil the others functions in limited range only, until it is rebooted again. The CU running in the A module can do store and forward relaying in the network, but in spite of this, it is recommendable to reduce the traffic in a heavily loaded network when downloading.

The (i)nit command in the “itl” can be used more often when we are in doubt about good progress of work, e.g. when switching to the A module.

The versions A or W older than 602 in one CU do not work with new (602 and later) sw in the second CU. It is recommended to replace them by version A602 or W602 or later, if available.

The modules ma10.rfr and mw10.rfr are contained in the firmware version 602.

©  2024 RACOM s.r.o. All Rights Reserved.