Unlike most of the software released by Energy Micro, the bootloader only comes with project files for IAR. The reason for this is simple - the code we release is the code that is factory programmed on every chip. Since this is a very critical piece of software we decided not to port it to several compilers. In addition, some compilers created bigger binaries than the 2048 bytes set aside for the bootloader.

To test the bootloader, you can use the provided binaries in the binaries/ folder of the application note. This will let you test your production workflow with as if the chips were factory produced.

However, in some cases you might wish to modify the bootloader to suit your application's needs. Fortunately, doing so is fairly straigth forward, however there are some caveats.

The #define XMODEM_DOWNLOAD_OFFSET defines where the bootloader will start writing the uploaded application. You need to make sure that this offset is bigger than the bootloader binary, and that the offset is a multiple of the page size (0x200 bytes on the Gecko).

Since the bootloader uses the debug pins (F0 and F1) to enter the debugger, normal debugging is impossible to perform on the complete bootloader. To help with debugging printf has been redirected to one of the UARTS. This is the purpose of the iarwrite.c file. This file can be safely ignored, along with debug.c, which sets up the debug UART. However, you can redirect printf to this UART using other toolsets as well. You can look at your compiler's documentation, or you can examine the RS232 examples for details on how to redirect print to a UART.

The code uses the IAR specific keyword __ramfunc. The purpose of this keyword is to instruct the compiler and linker to put the function in RAM. The bootloader uses this functionality to load itself into RAM so that the bootloader will still function after it has been completely overwritten by a destructive upload. If you don't need destructive upload functionality you can safely remove this from most of the code. The exception is the code that actually writes or erases flash. These must reside in RAM, or the EFM32 will lock up. For details on how to convert __ramfunc examine your compiler's documentation, or you can examine the msc functions in efm32lib.

In addition, the code uses #pragma location=X. This keyword forces IAR to place certain objects at predefined addresses. In most cases, this has been used to reduce the footprint, but in some cases (such as the DMA descriptors), the keyword has been used to force an alignment. In this case a #pragma data_align would have sufficed. Consult your compiler documentation on how to force alignment or locations. You can also look at the DMA examples such as preamp and wavplayer for details on how to force alignment for some supported IDEs.

Fortunately, porting the