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.
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 |
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 |
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.
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
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 |
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
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 onethe 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 |
---|---|
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.