Storing two applications in the Netburner....

[pbreed]

For 12 years I've been answering the question:
Can we store two applications in our Netburner and if one is bad boot to the other.

My argument has always been most apps that fail fail because the program has a bug, not because of corrupted flash,
so how do you tell the difference between a good app and a bad app.
I also argue that the way autoupdate works flash corruption is really rare.
As of today I gave up this particular fight.

Soon you can have two apps stored in the system and boot to the alternate if bad things happen.
I have this working for the MOD5272 today and this will get rolled out as alternate monitors for all of our
network producs (except the SBL2E) and it will work as follows.


You the programmer get to decide how much of your flash space you set aside for the main and backup application.
I'm going to use the MOD5272 as an example.
The FLASH in the MOD5272 is setup as follows:

FFC00000 to FFC03FFF The boot monitor code
FFC04000 to FFC05FFF The IPsetup or Monitor config record.
FFC06000 to FFC07FFF The user param space.
FFC08000 to FFE00000 The application compressed image storage.

The code stored starting at FFC08000 is actually a small boot header followed by a compressed image of the code.
On boot up the monitor takes this image and decompresses it to RAM then jumps to it.
Other than the fact that the monitor is looking for it here there is nothing special about the FFC08000 location.


So one could imagine a memory map that looked like:

FFC00000 to FFC03FFF The boot monitor code
FFC04000 to FFC05FFF The IPsetup or Monitor config record.
FFC06000 to FFC07FFF The user param space.
FFC08000 to FFDE0000 The application compressed image storage.
FFDE0000 to FFE00000 The 2nd application compressed image storage.

We have now shrunk the amount of space available for the Main app and made 128K available for an alternate app.

How do we create these application compressed images?
The build process is as follows: (assume the project name is PROJ)

Your code is compiled and makes a PROJ.elf file
objcopy is called and turns this elf into a PROJ.s19 file.
This is a S19 record that represents what the application will look like when loaded in RAM.
We then run compcode and compress that PROJ.s19 file, add the startup header and relocate it to FFC08000
and creates the file PROJ_APP.s19
Compcode knows where to locate this because of the compcode flags....

FFC00000 FFE00000 The first value is where to start storing the compressed image and the 2nd value is how much space we have available.

So if we change the compcode flags to

FFC00000 FFDE0000 for the main app
and
FFDE0000 and FFE00000 for the backup app we now have two _APP files that can BOTH be loaded into flash via autoupdate.
The normal monitor will still just start the first app. (as it expects the app to be at FFC08000)


For legacy reasons we REALLY don't want to modify the config record as set by IPSETUP or by the setup command in the monitor.
So the concept will work as follows:

What I have changed is to add 3 new features to the Monitor.
The primary reason to use the monitor TFTP functionality is to rapidly reload code when your app crashes a lot.
so if we can load two apps this is much less needed.

IF you do nothing special the new monitor works just like the old monitor in ALL ways.
If you put a special command in the TFTP file name either with setup or with IPSETUP then its behavior changes:

Feature #1 Backup app.
TFTP_File name: B:XXXXXXXX
where XXXXXXXX is the hex address of the alternate app storage (It would be B:FFDE0000 in the example above)
Then if the primary app is corrupt or does not decompress properly it loads the alternate app.

Feature #2 Alternate APP:
TFTP_File name: A:XXXXXXXX (It would be A:FFDF0000 in example above)
In this case the system ALWAYS boots the alternate app.


Feature 3
A new monitor command (say your app traps and returns to the monitor. Or you catch a bad app on boot with A to abort to the monitor.)
ABOOT

IF and only IF an alternate app is loaded and is stored in the TFTP file name via C:XXXXXXXXX (C can be A,B, or any other char)
then ABOOT will boot that alternate app.


Several Side notes:
The smallest alternate APP space you can reserve is 64K, next bigger is 128K , 196K etc....
The default stuff in the system has grown to the point that a minimalist app compresses to about 70K
This is because it links the TCP library and some other pieces that aren't needed for a minimalist autoupdate app.
By doing some trickery including some dummy functions like InitTCP etc... I can build an app that
does DHCP and AUTOUPDATE and compresses to less than 64K with no library changes.
This will also be part of the release that includes the modified monitors and be called something like tiny update or some such.
With some real work I could probably shrink this to 16K, alas there is no benefit for this as min size is 64K)

Playing with comp code flags:
If you are in the stone age like I am and build everything from the command line then just add the following as the first line in your make files:
COMPCODEFLAGS = 0xFFDE0000 0xFFE00000
Values need to change if you are building a normal or backup app.


Eclipse already lets you mess with the compcode flags as some people reserve flash space for a flash based file system.
From our Eclipse guru Forrest...
Instructions for modifications of compcode options in NBEclipse:

You can make the changes described below in NBEclipse as well. To do
this, right click on your project and select properties. Under C/C++
Build->Settings, go to NetBurnerCompcode->General. Here you can change
the compcode range as specified below. Make your change and click
apply. If you intend to debug the application you should also change the
configuration pulldown at the top to debug and make the change as well.





Paul

[cbyrne]

What exactly is the second compcode parameter used for -- anything other than checking if the image will fit in the allotted space?

[pbreed]

The 2nd parameter sets the upper limit and is used to
report:
Overflow of the area
Percent used.

Paul

[greengene]

we use modifying that last number, BigParamBase, to put some
extra user data into flash ala the "How to Increase User Flash Storage"
app note.

[pbreed]

As long as you have the space and each thing aligns on a 64K boundary
then this scheme allows oyu to have main app, alternative app and big user params...
all at the same time.

Paul