Hex file, binary file and relocating an application to different address

lpcware · ‎06-15-2016

Content originally posted in LPCWare by sangamesh.vandal on Sun Dec 01 23:33:49 MST 2013
Hi,
We are using LPCXpresso v5.2.6_2137

we have customized boot loader and an application, we want our application to start from 0x3000 address

1) please help us in relocating the application from 0x3000 address.

2)following is the command used in post build steps for application to create .hex and .bin file, please let us know is command correct

arm-none-eabi-size "${BuildArtifactFileName}"; arm-none-eabi-objcopy -O ihex "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.hex" ; arm-none-eabi-objcopy -O binary "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.bin" ; #checksum -p ${TargetChip} -d "${BuildArtifactFileBaseName}.bin";

3)following are the last few lines of intel hex file, in last but one line the record type is 3 what should we do with record type 3 , how to handle it, in the equivalent binary file last two lines will not be there.

:1016E000004B00000096000000E1000000C2010075
:1016F000003200000084030090D0030000E80300E3
:1017000000D0070000A00F0000401F0000803E0036
:1017100001000000010F00008C0900108C01001076
:041720000101FFFFC5
:040000030000010DEB
:00000001FF

to summarize
please help us in relocating the application to 0x3000 location, how to handle record type 3 in intel hex file is our post build command correct.

Thank you

lpcware · ‎06-15-2016

Content originally posted in LPCWare by TheFallGuy on Wed Dec 18 06:45:04 MST 2013
No. There is NO DATA at this location. That is why it contains 0xff - it is BLANK, it has not been written. It must be because your files do not contain data.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Lumos on Wed Dec 18 06:31:21 MST 2013
No, I mean generated hex/bin file contains this area, it means when I load such file, data at this location will be overwritten by FF. Correct hex file should not contains this area.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by TheFallGuy on Wed Dec 18 06:17:45 MST 2013
Un-programmed (blank) flash has the value of 0xff. If you want a different value, you are going to have to program it to that value yourself.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Lumos on Wed Dec 18 05:31:08 MST 2013
The situation changed little bit, I do not need small application at the beginning of the flash.
I need only create empty memory area after vectors.
For this I edit linker script - I added:

. = 0x00001000 ;
KEEP(*(.flash_storage))
. = 0x00003000 ;

this is working fine, there are vectors from 0x0, empty space until 0x3000 and my application.
Problem is only that memory space from 0x1000 - 0x3000 is initialized to FF.
Do you know about some command/pragma or something like this for avoiding of initialization of empty space?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by TheFallGuy on Fri Dec 13 04:11:50 MST 2013
Why are you using such an old version of LPCXpresso? Latest version is v6.1.2

Anyway, look in the RDB1768_cmsis2 examples - there is an example of a bootloader, and several bootloadable applications. Instructions/information is in the example projects

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Lumos on Fri Dec 13 03:51:02 MST 2013
Hello, I am solving the similar situation - I would like to shift my application to location 0x3000.
in page 1: 0x0000 - 0x0FFF will be located small application with jump to the main application
in page 2, 3: 0x1000 - 0x2FFF will be located storage space (for storage of configuration data)
from page 4: 0x3000 - open end will be located main application

I am using LPC1769 board and LPCXpresso 5.2.2 environment.

I am looking for some way how to shift application location to 0x3000 directly from LPCXpresso by changing of some setting. Such possibility is availabe in the Keil for example.
Do you know if there is such option also in LPCXpresso?

Thank you

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Dore on Mon Dec 09 00:12:35 MST 2013
Thanks a lot!

Got the solution. Relocating the vectors to the local RAM and change the SYSMEMREMAP to 0x01 which takes care of the relocation successfully.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Dore on Mon Dec 09 00:12:30 MST 2013
Thanks a lot!

Got the solution. Relocating the vectors to the local RAM and change the SYSMEMREMAP to 0x01 which takes care of the relocation successfully.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by MikeSimmonds on Sun Dec 08 12:11:55 MST 2013
When my application (based at 0x2000) gains controlm one of the first things that I do is to *completely*
re-initialise the NVIC system.

1. disable all interrupts (including pending interrupts)
2. setup (via code) a new interrupt table (at the bottom of sram)
each entry is set to a dummy handler (most to a single general purpose
missing handler).
3 Set all interrupt priorites to the lowest
4 Relocate the vector table to the ram table I just created.

At thid point, no interrupts are being handled -- anything unexpected goes to a dummy.

Now, as I setup the various peripherals and timers etc.,
I can call my 'SetHandler' (or 'SetTimer') routine that ...
(a) writes the handler address into the ram based memory table
(b) sets the priority that I want
(c) enables the interrupt so it will be invoked as appropriate.

I make the call as part of the setup whenever I need an interrupt handler.

The point to take away is that I do not use a hard coded table (such as all the example projects do)
but arrange things so that I can dynamically add a handler as and when I want.

I write directly in assembler, but you might pickup clues from the comments

;-----------------------------------------------------------------------!
; Setup the Interrupt System!
;-----------------------------------------------------------------------!

fn InitNVIC

;---------------------------------------;
movsr3, sramBase; vector table
movsr0, 0;
strr0, [r3], 4; stack <used for tick count>
strr0, [r3], 4; reset <used for day roll over >
ldrr1, =NMI;
strr1, [r3], 4; NMI
ldrr1, =HardFault;
strr1, [r3], 4; Hard Fault
ldrr1, =MMFault;
strr1, [r3], 4; Memory Management Fault
ldrr1, =BusFault;
strr1, [r3], 4; Bus Fault
ldrr1, =UsageFault;
strr1, [r3], 4; Usage Fault
strr0, [r3], 4; unused
strr0, [r3], 4; unused
strr0, [r3], 4; unused
strr0, [r3], 4; unused
ldrr1, =Missing;
strr1, [r3], 4; SVC
strr1, [r3], 4; Debug Monitor
strr0, [r3], 4; unused
strr1, [r3], 4; Pending SVC
ldrr2, =SysTick;
strr2, [r3], 4; SysTick

movsr2, nIrq; now all the peripheral IRQs
0:strr1, [r3], 4;
subsr2, 1;
bne0b;

;---------------------------------------;
movsr3, sysBase; Cortex system control block
mvnsr1, r0;
strr1, [r3, irqClrEnable]; disable all irq
strr1, [r3, irqClrEnable2];
strr1, [r3, irqClrPending]; clear all pending
strr1, [r3, irqClrPending2];

movsr1, (0<<8); set sub-priority bits (1)
movtr1, 0x05FA; access key
strr1, [r3, sysReset];

movsr1, (1<<9)+(0<<4)+(1<<3); StackAlign/!DivZero/UnalignTrap
strr1, [r3, sysConfig];

addsr0, r3, irqPriority; reset all priorities to lowest
movsr2, nIrq;
movsr1, (31<<3);
0:strbr1, [r0], 1;
subsr2, 1;
bne0b;
strbr1, [r3, sysPriSysTick]; including the sys tick handler

movsr1, (0<<3); highest 3 priorities for faults
strbr1, [r3, sysPriBF]; bus fault
movsr1, (1<<3);
strbr1, [r3, sysPriMM]; mm fault
movsr1, (2<<3);
strbr1, [r3, sysPriUF]; usage fault

;---------------------------------------;
movsr1, sramBase; relocate the vector table
strr1, [r3, sysVTab];

movsr1, (1<<18)+(1<<17)+(1<<16); enable the fault handlers
strr1, [r3, sysFaultEnable];

bxlr; return

fe InitNVIC

and the SetupHandler

;-----------------------------------------------------------------------!
; SetHandler!
;-----------------------------------------------------------------------!

; r0 = irq (0..41), r1 = handler, r2 = priority (0..28)

fn SetHandler

cmpr0, nIrq; irq legal?
bhs9f; nope
movsr3, sramBase; vector table
addsr3, 16*4; skip system vectors
strr1, [r3, r0, lsl 2]; stash handler address

cmpr2, nPri; validate priority
blo1f; ok
movsr2, nPri-1; oops -- force valid
1:addsr2, 3; allow for fault priorities
lslr2, 3; shift into place

movsr3, sysBase; using adjusted priority
addsr1, r3, irqPriority;
strbr2, [r1, r0]; 

lsrsr2, r0, 5; word = irq/32
andsr1, r0, 32-1; bit  = irq%32
addsr3, r3, r2, lsl 2; adjust for correct word
movsr2, 1; calc bit mask
lslr2, r1;

strr2, [r3, irqClrPending]; just in case
strr2, [r3, irqSetEnable]; and enable the interrupt
9:bxlr; return

fe SetHandler

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Dore on Sun Dec 08 04:45:23 MST 2013
Hi,

I am also coming across this situation.
I am able to relocate my application and jump from the boot loader to the application. As per the suggestion from AN10995.
I had the issue with the execution of the interrupts of the application. Then as per the suggestion I have redirected the service routines from the boot code to the application code (which starts from 0x3000).
Similar to the one:
void TIMER16_0_IRQHandler(void)
{
/* Re-direct interrupt, get handler address from application vector table */
asm volatile("ldr r0, =0x3080");
asm volatile("ldr r0, [r0]");
asm volatile("mov pc, r0");
}

But In this case both the boot code and the app code will execute the same routine for the timer interrupt. In my case I would like to different operation for the interrupt exclusively in boot & application. How can i do that, any suggestions?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by TheFallGuy on Mon Dec 02 06:29:45 MST 2013
Maybe you had better explain what the real problem is. You HAVE relocated your application (including the vectors). My guess is that your bootloader is not calling your application properly. But it is only a guess because you have not given us any details on what the problem really is.

BTW: did you read the README.TXT in the RDB1768 bootloader examples? This explains how to relocated AND debug your application.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by R2D2 on Mon Dec 02 05:20:17 MST 2013

Quote: sangamesh.vandal
...2)following is the command used in post build steps for application to create .hex and .bin file, please let us know is command correct

arm-none-eabi-size "${BuildArtifactFileName}"; arm-none-eabi-objcopy -O ihex "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.hex" ; arm-none-eabi-objcopy -O binary "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.bin" ; [color=#f00]#[/color]checksum -p ${TargetChip} -d "${BuildArtifactFileBaseName}.bin";

Are you aware that you've excluded checksum calculation?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by sangamesh.vandal on Mon Dec 02 05:00:15 MST 2013
Hi

we have already modified our Linker script which starts from 0x3000, but when we program the code it gives error saying No source available at 0x......(different value at different times)

following is the Linker script
MEMORY
{
/* Define each memory region */
MFlash32 (rx) : ORIGIN = 0x00003000, LENGTH = 0x5000
RamLoc8 (rwx) : ORIGIN = 0x10000000, LENGTH = 0x2000 /* 8k */

}
/* Define a symbol for the top of each memory region */
__top_MFlash32 = 0x00003000 + 0x5000;
__top_RamLoc8 = 0x10000000 + 0x2000;

lpcware · ‎06-15-2016

Content originally posted in LPCWare by TheFallGuy on Mon Dec 02 02:15:26 MST 2013
Look in the RDB1768 examples - there are some projects that relocate to 0x4000. You can use the same technique to relocate your code.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by capiman on Mon Dec 02 00:39:53 MST 2013
You cannot just change the hex file. There are addresses inside (in general) your code which need also be changed.
I don't know how this is done with LPCXpresso, but in general, there is a linker script where the area of flash is defined.
You need to adapt the start address to 0x3000.