Secondary bootloader, AN10744_1, does not start app code.

Started by deeaitch, April 07, 2009, 07:00:07 AM

Previous topic - Next topic

deeaitch

Hello!

I am new at the bootloader thing, so perhaps it is an abvious answer to my problem...

I am using the Ethernet bootloader code found in the installation package of FlashMagic. My device is LPC2366 running at 70MHz.
My main application is a FreeRTOS application with a bunch of tasks.

Equipment:
LPC2366 +Phy for Ehternet
Rowley IDE + CrossConnect USB debugger

First things first, the application note AN10744 sais that the bootloader requires the first 0x00000000 0x00002000 flash memory range. But when I compile the code demands much more. Is it normal? Is it my GCC compiler that is less good than others?

Well, well, now to the real problem...
I locate the bootloader at flash address 0x00000000 and the main application at 0x00005000, setup the sbl_config.h with the proper parameters and download the two codes to their dedicated places. (I place the app code at 0x00005000).
Now, when the device is reset it shall start the app code, but it does not.

Just for testing, I have cut out the bootloader entry functions and just place the execute_user_code(); at the sbl_main() start. When looking at the dissassembly, it looks like the bootloader jumps to 0x00005000 as it should. But then it stops in a loop.

The main app is set with
#define VECTORED_IRQ_INTERRUPTS
#define SRAM_EXCEPTIONS
in its startup.s file.

I guess much more info is neede here, but so far, is there any obvious reasons why the bootloader does not fire up the main application at 0x00005000 as it should?

/D

Andy Ayre

If the bootloader is jumping to 00005000H where the start of your application is then the problem must be in the way you relocated your application to start at 00005000H.

I suggest you try programming your code using the UART based bootloader (as a test) then use the "Go" feature in Flash Magic to start execution at 00005000H. If it doesn't work then you need to check how you have GCC configured to relocate your code.

The supplied hex file was built using the Keil RealView compiler and uses locations 00000000H -> 000015B3H.

Andy
Embedded Systems Academy, Inc.
support at esacademy dot com

deeaitch

Hi Andy and thanx for the reply.

Ok, I will test that solution....
Hehe, well, 0x15B3 is much lower than what I get in Rowley GCC tool. Strange how big difference it is, perhaps there is something wrong there to...
I will test and coma back here again.

Btw. In the application note, both the bootloader and the application code seams to have a Startup.s file included allthough only the folder is shown in one of the cases. When I am thinking about it, shall it not be only ONE startup.s (located in the bootloader code)?
Also, there is a difference between the two LPC2300.s files used by the bootloader and the "Blinky" application... I am trying to see what the difference is, allthough I am not an assembler expert.

Rowley IDE uses Philips_LPC230X_Startup.s as startup file and that is what I have replaced LPC2300.s with. My early guess is that there is a smelly fish somewhere in this file...

I have digged more into what happends at the jump from the bootloader to the app code. Here is a screen dump of the assembly:

    user_code_entry();
      E51B3010   ldr r3, [r11, #-0x010]
      E1A0E00F   mov lr, pc
      E12FFF13   bx r3

When the code reaches the last row above, it jumps to the correct address 0x00005000 were hte following code is:
E59FF018   ldr pc, [pc, #+0x018]

Now, when executing the row above, the code jumps to address 0x00005318 were the following line is:
EAFFFFFE   b 0x00005318

I will write more when I have found out more.... brb

deeaitch

Hi Andy.

I think I got it to work now... And the hex file for the ethernet bootloader is ~50kB! Is it not a bit to large you think?

/D

Andy Ayre

What was the solution?

The size of the hex file isn't the same as the size of the code when programmed into Flash memory. The hex file built using the Keil Realview compiler is 15.4kB. Not sure why the GCC compiler would produce such a big hex file.

Andy
Embedded Systems Academy, Inc.
support at esacademy dot com