What is the extra information in my .HEX file?

You have all convinced me that I'm not going to get this to work reliably till I separate the bootloader from the app.

Thanks for all your help! Wish me luck!

Todd

You have all convinced me that I'm not going to get this to work reliably till I separate the bootloader from the app.

Thanks for all your help! Wish me luck!

Todd

"developing the bootloader and the main application as a single program"
is a quite standard way here in my current company; and of course, it works well.

"What seems to work will fail when you are in most need of it to work."
It fails, mainly because a MCU design flaw, and/or a compiler design flaw.

The bootloader I developed is a freak for my current company.

My bootloader is able to dump the content of flash, so that I can compare the HEX file with the programmed flash to make sure the flash programming is successful. Of course this is a totally unnecessary functionality.

--
Hopeless Battle.

So if your company is making one compile/link pass that ends up generating both a boot loader and an application - how have you managed to get the compiler/linker to not call any helper function that gets stored in one memory area from the other memory area?

Or is the boot loader written 100% in assembler?

The nice thing with building both in the same step is that it looks like it works, until you make the wrong type of changes in the code. Suddenly a change in the boot loader generates changes in the application area. Or a change in the application generates changes in the boot loader area. And when that happens, you are in a deep pile of ***. The equipment already shipped can't be updated until the problem is solved. But if the shipped boot loader has a reference into the application area, you just have to figure out how to get the compiler to produce a new application that still has the exact same contents at that location.

By the way - all boot loaders are expected to have code to verify that they correctly program the application area. But that is something completely different from having a boot loader that doesn't contain unexpected, "hidden" references into the application area, that makes the boot loader fail after an update of the application.

is a quite standard way here in my current company; and of course, it works well.

The bootloader I am commonly using has a small dependency between it and the application in the form of a piece of RAM telling the bootloader whether it should perform IAP, in addition to some checksums of the data and the location of the data in RAM. No explicit dependencies exist beyond that - otherwise, the thing is becoming one program, really...

A shared memory region for parameter passing isn't a problem as long as that memory region is protected from having the linker place any other variables there.

The problem is when both linker and application uses shared code, and the access to that shared code isn't implemented in a "BIOS-style" way with a predefined entry point and pre-defined parameter-passing method.

The "traditional" way many people implement a single-build boot loader + application is that they first builds one binary and program their device with. Then they change the version string of the application and have the boot loader update the device with the new application. Then they verify that their device now reports the newer application version.

It may seem like a working test, to verify that the boot loader works. But just changing a n-character version string to another n-character version string will not trig all the failure situations where the boot loader and application has cross-linked code and data references. So more than one company have managed to ship broken boot loaders and not noticed until they need to create a bug fix or add more functionality to the application. Then they have to fix their boot loader and have the customers send in the equipment just because the remote update can't be used. And management looks at each other and can't understand why, since they just knew that the remote download functionality was tested before shipping started...

And management looks at each other and can't understand why, since they just knew that the remote download functionality was tested before shipping started...

Now working on the first product that will update itself and associated bluetooth devices via the Internet. I am making sure this kind of failure does not bite me...

What is the proper way to "link" the application to the bootloader. In other words how should the bootloader call the application without needing a common included file?

Previously I had a "start vector" memory location setup in the scatter file and a simple fuction that resided there that called the main() function in my application. The applications main() function was renamed to main_startup so as not to be confused with the bootloaders main() function. Now with both programs is separate projects I'm having difficulty getting this to work because I can't reference a function that doesn't exist.

Thanks,

Todd

There is nothing forbidden about having a common include file. It's probably quite common to allocate a couple of bytes of RAM for a info structure where boot loader and application can share information.

Maybe the application wants to force a change of program so it sets a magic value in this structure before forcing a watchdog reset.

Maybe the boot loader wants to report some version or statistics to the application - or potentially information that "application region 'A' contains a broken binary".

The problem isn't on the source-code level, but a problem with the linker linking both application and boot loader at the same time. With both linked at the same time, the linker will give them shared helper variables (lots of them from the CRTL) and helper functions.

But the "normal" way to start the main application is to know that the start of the application area stores the applications vector table, which means the boot loader always knows a fixed location relative of the start of the memory region allocated for the application code, where it can pick up a suitable start address.

It's common that the boot loader contains one vector table. Then, before it starts the application, it turns off all interrupts, and then makes use of the reset vector in the applications vector table to activate the application.

So no need for any entry function name or location to be known - the position of the reset vector has a hard-coded offset in the interrupt vector table.

What is the proper way to "link" the application to the bootloader.

By not actually linking at all. If you need to do more than just merge the HEX file of the boot loader with that of the application (or load both files for a debugging session), your bootloader is quite likely not going to work.

The bootloader sets a small number of fixed addresses which are then used in the application. One of those is either the entry point of the application image, or the location of a pointer to that entry point. The easiest way is for the application to have its interrupt entry / interrupt vector table in the normal memory layout, but a different location. The boot loader then starts the application the same way the CPU itself starts up after a reset --- but with a different base address of the vector table. You even can express code like that in C, if you feel sufficiently lucky:

typedef void (*T_EntryPoint)(void); // function pointer type
/*...*/
((T_EntryPoint)0x10000)();  call function at location 0x10000
(*((T_EntryPoint *)0x10000))(); call function whose address is stored at 0x10000

I found this in one of the nxp app notes for a bootloader (AN10835):

#define AP_ADDR 0x10000// where the user app located
typedef void (*FP)(void);

/** run the user application from pre-specified address*/
void Run_Application(void)
{ FP fp;
 fp = (FP)AP_ADDR;
  (*fp)();

When debugging the bootloader, it did set the PC to 0x10000, so i think that means its working.

I'm trying to get the main application to work right now. As soon as I change IROM1 from a start value of 0x00000000 to a start value of 0x00010000 the program will no longer operate properly. It keeps getting stuck in an endless loop in a section called "decompress2". What am I missing...?

It keeps getting stuck in an endless loop in a section called "decompress2". What am I missing...?

You're probably missing some modifications to the application's copy of the startup code. The routine you're stuck in is the code that sets up initial values for the application's initialized variables from the master image. It's quite possible that this code needs to be informed separately about where you moved the entry point.

Is this likely to be in the target options setup or in the code itself?

I'm trying to get the application code to run by itself without the bootloader, to verify it works when loaded at 0x10000. So far it will only work if I load it at 0x0. I have tried changing the settings for the ulink2, the scatter file & the target options. So far I'm striking out. Same problem as above with the endless loop. I don't know where or what to search for.

Someone please tell me I'm an idiot and the easy fix is X....

Here is my scatter file:

; *************************************************************
; *** Scatter-Loading Description File generated by uVision ***
; *************************************************************

LR_IROM1 0x00010000 0x00070000  {    ; load region size_region
  ER_IROM1 0x00010000 0x00070000  {  ; load address = execution address
   *.o (RESET, +First)
   *(InRoot$$Sections)
    RTX_Conf_LPC23xx.o (+RO)
    LPC2300.o (+RO)
        SSP_Display.o (+RO)
    SSP_Keyboard_Task.o (+RO)
;    ghwbuf.o (+RO)
    ghwinit.o (+RO)
    ghwioini.o (+RO)
    SSP_Menu_Task.o (+RO)
    SSP_Util.o (+RO)
    SSP_SPI.o (+RO)
    Retarget.o (+RO)
    SSP_IO.o (+RO)
    SSP_CRC16.o (+RO)
    SSP_ISR.o (+RO)
    SSP_Graph.o (+RO)
    SSP_Logfile.o (+RO)
    SSP_MaintPort_Task.o (+RO)
    SSP_Aux485Port_Task.o (+RO)
    SSP_Param.o (+RO)
    RTC.o (+RO)
    SSP_Relay.o (+RO)
    SSP_ProbeComm_Task.o (+RO)
   *LCDDRV.lib (+RO)
   .ANY (+RO)
  }
  RW_IRAM1 0x40002000 0x00010000  {  ; RW data
    RTX_Conf_LPC23xx.o (+ZI +RW)
    LPC2300.o (+ZI +RW)
   .ANY (+RW +ZI)
  }

Hi Todd,

Maybe see this:
http://www.keil.com/forum/13707/

Search for "Predrag Despotovic" and "13-Dec-2008 12:07 GMT"
Follow the instructions and configure your startup code properly.

RAM_INTVEC and REMAP

; * RAM_INTVEC: when set the startup code copies exception vectors
; * from on-chip Flash to on-chip RAM.
; *
; * REMAP: when set the startup code initializes the register MEMMAP
; * which overwrites the settings of the CPU configuration pins. The
; * startup and interrupt vectors are remapped from:
; * 0x00000000 default setting (not remapped)
; * 0x40000000 when RAM_MODE is used
; * 0x80000000 when EXTMEM_MODE is used

I've been using the LPC2300.s but after reading the above thread I discovered it does not contain the code for RAM_INTVEC. So I changed over to the LPC2400.s and got it to compile and load to my target. It also will run properly on the target.

I then changed the IROM1 from this:

LR_IROM1 0x00000000 0x00080000  {    ; load region size_region
  ER_IROM1 0x00000000 0x00080000  {  ; load address = execution address

to this:

LR_IROM1 0x00010000 0x00070000  {    ; load region size_region
  ER_IROM1 0x00010000 0x00070000  {  ; load address = execution address

added RAM_INTVEC to Options/target/asm/define
complied and loaded the ulink 2 debugger. It is NOT setup to run to the main (). the debugger starts at 0x00000000 and when it gets to 0x000000010, the PC jumps to 0xFFFFFFF3 and crashes.

If I debug using the Simulator, and an ini file to allow execution in 0x40000000, it will actually start at address 0x00000000 which is an ANDEQ instruction (that area all the way to 0x0000ffff is all zeros) and then it gets lost in the os_sys_init function, never returns.

What am I doing wrong?

0x00000000  E59F4018  LDR       R4,[PC,#0x0018]
0x00000004  E59F5010  LDR       R5,[PC,#0x0010]
0x00000008  E5946000  LDR       R6,[R4]
0x0000000C  E0056006  AND       R6,R5,R6
0x00000010  E5846000  STR       R6,[R4]
0x00000014  E51FF004  LDR       PC,[PC,#-0x0004]
0x00000018  7FFFE040  SWIVC     0x00FFE040
0x0000001C  FFFFBFFF  (???)
0x00000020  3FFF8000  SWICC     0x00FF8000
0x00000024  00000000  ANDEQ     R0,R0,R0
0x00000028  00000000  ANDEQ     R0,R0,R0
0x0000002C  00000000  ANDEQ     R0,R0,R0
0x00000030  00000000  ANDEQ     R0,R0,R0
0x00000034  00000000  ANDEQ     R0,R0,R0
0x00000038  00000000  ANDEQ     R0,R0,R0
0x0000003C  00000000  ANDEQ     R0,R0,R0
0x00000040  FFFFFFFF  (???)
0x00000044  FFFFFFFF  (???)
0x00000048  FFFFFFFF  (???)
0x0000004C  FFFFFFFF  (???)

0xFFFFFFF1  FFFF      (???)
0xFFFFFFF3  FFFF      (???)
0xFFFFFFF5  FFFF      (???)
0xFFFFFFF7  FFFF      (???)
0xFFFFFFF9  FFFF      (???)
0xFFFFFFFB  FFFF      (???)
0xFFFFFFFD  FFFF      (???)

Your processor always starts at address 0. Which is why you need a boot loader (or help from JTAG interface to play with the program counter) to get it to enter your application.

Since you already know about the boot loader issue, I'm a bit confused about what you mean with "start at address 0" - your simulator ini file (or your boot loader) would make sure the execution starts where it should in the application area which means it's this area you should dump if you don't agree about the contents.

Another thing - the processor core do only support the interrupt vector table to start at address 0. So the remapping of the vector table does not move it. It just makes a very specific part of the RAM area to overlay the original ROM contents at address 0. So an application starting at 0x1000 have the interrupt vector copied into RAM and that RAM region mapped to show up at address 0.

After this has been correctly done, memory reads at address 0 and forward should show same contents as address 0x1000 and forward and same contents as that RAM region.

Note that newer ARM cores can remap where the interrupt vector table is stored - but older ARM cores relies on the external memory controllers to remap the address lines to make other memory show up at address 0.