26
You may notice, in the top level discussion, that the two above routines, ret_boot() and exe_main() are called from
differing positions in the code. While this is common practice for a subroutine, we do not want to return from these
routines as a subroutine normally would return. The desired operation at the invocation of either of these routines is to
precipitate a system reset. This allows desired memory swap to occur bringing the new code into execution position.
How to create your own app for UART Download
Typically, getting a single application to run is relatively straightforward as the linker (and user) make sure all
references are resolved when the executable file is created. Setting up your application for UART download takes only
a little more coordination between the two executable files; specifically in the area of code placement and the linker.
Typically no code changes are required.
First,a quick review of what were trying to do. We are attempting to smoothly transition from one running application
to another. The microcontroller will initiate the action, but be substantially unaware of its occurrence. We are going to
accomplish this by manipulation of the code memory presented to the microcontroller.
Certainly this will take some coordination between the two applications, but probably not as much as you might initially
think. To make things easier, well do this critical transition just after a system reset as described in A detailed look at
the IAP example implementation section earlier in this document. This reset can be initiated either through software or
hardware means based on the method(s) available in your system.
You can tailor the scheme as described earlier in this document, or utilize the key generic elements listed below;
1. Startup routine placed identically in both applications
2. Flag indicating desire to jump from BOOT memory to main memory. The demo uses the variable source
described in the previous section.
3. Method to tell system of desire to return from main memory to BOOT memory. The demo uses the User
Defined command (ASP) with an argument of RET described in the previous section.
When using a PSD, we recommend the use of our startup.a51 routines or an equivalent included in the code bundles.
The specifics of the VM and PAGE registers are already worked out for your convenience. The code placement issues
are serviced in the file itself with conventional CSEG at statements resulting in no linker directives being needed.
For STEP 2 (flag indicating desire to jump from BOOT memory to main memory; Nvswap or source), the
described flag should be set after the downloaded code is successfully transferred and validated. Then, after the system
is rebooted, the new location is automatically delivered. Depending on your application, this element can be either
volatile or non-volatile. The motivation to use a non-volatile method is that the desired boot source can be carried
through a power outage. If a volatile medium is acceptable in your application, a convenient holder for this variable is
the internal PSD ram.
For STEP 3 (method to tell the system of desire to return from main memory to BOOT memory), the method can be
conveyed to the software by virtually any means from a simple mechanical switch or, for remote operation, via some
communications medium. Once this is done, the ret_boot() is run, manipulating the VM and PAGE register to the
desired states and rebooting the system.
The code content and positioning after the initialization code (startup.a51) need have no correlation between the two
applications. That is, the linker can be allowed to handle post initialization code without ill effects to the desired
swapping operation. This element eases the creation of compatible applications as all the critical code placement is
handled within a single file; startup.a51.