Hello,
I have a simple assembly startup file for and ARM7 (LPC2478) when I debug this code the disassembly seems odd to me. could someone explain the following:
Note: this is the mix mode view of the disassembler:
1054: Vectors LDR PC, Reset_Addr 0x00000000 E59F4018 LDR R4,[PC,#0x0018] 1055: LDR PC, Undef_Addr 0x00000004 E59F5010 LDR R5,[PC,#0x0010] 1056: LDR PC, SWI_Addr 0x00000008 E5946000 LDR R6,[R4] 1057: LDR PC, PAbt_Addr 0x0000000C E0056006 AND R6,R5,R6 1058: LDR PC, DAbt_Addr 0x00000010 E5846000 STR R6,[R4] 1059: NOP ; Reserved Vector 1060: ; LDR PC, IRQ_Addr 0x00000014 E51FF004 LDR PC,[PC,#-0x0004] 1061: LDR PC, [PC, #-0x0120] ; Vector from VicVectAddr 0x00000018 7FFFE040 SWIVC 0x00FFE040 1062: LDR PC, FIQ_Addr 1063: 1064: Reset_Addr DCD Reset_Handler 1065: Undef_Addr DCD Undef_Handler 1066: SWI_Addr DCD SWI_Handler 1067: PAbt_Addr DCD PAbt_Handler 1068: DAbt_Addr DCD DAbt_Handler 1069: DCD 0 ; Reserved Address 1070: IRQ_Addr DCD IRQ_Handler 1071: FIQ_Addr DCD FIQ_Handler 1072: 1073: 0x0000001C FFFFBFFF (???) 0x00000020 3FFF8000 DD 0x3FFF8000 0x00000024 00000000 DD 0x00000000 0x00000028 00000000 DD 0x00000000 0x0000002C 00000000 DD 0x00000000 0x00000030 00000000 DD 0x00000000 0x00000034 00000000 DD 0x00000000 0x00000038 00000000 DD 0x00000000 0x0000003C 00000000 DD 0x00000000 1074: Undef_Handler B Undef_Handler 1075: ;SWI_Handler B SWI_Handler 0x00000040 EAFFFFFE B 0x00000040 1076: PAbt_Handler B PAbt_Handler 0x00000044 EAFFFFFE B 0x00000044 1077: DAbt_Handler B DAbt_Handler 0x00000048 EAFFFFFE B 0x00000048 1078: IRQ_Handler B IRQ_Handler 0x0000004C EAFFFFFE B 0x0000004C 1079: FIQ_Handler B FIQ_Handler 1080: 1081: IMPORT SWI_Handler 1082:
So specifically I don't understand the disassembly of the vector table?
Thanks
Mac
But address 0x0000 need not be the internal flash. Have you verified that your program haven't swapped in a bit of RAM on top of the interrupt vector table in flash in which case RAM corruption can result in very strange data being disassembled from address 0?
Yes, you are correct. The MEMMAP register of this device and set the reset vector locations however I am using the setting for internal flash so as far as I can tell in my setup 0x000 is the start of internal flash.
Thanks.
M
I have another question.
Does anyone know if Keil + ULINK Pro calculates the 2's complement of the vector table and inserts this in location 0x14?
From the LPC2478 user manual:
Criterion for valid user code: The reserved ARM interrupt vector location (0x0000 0014) should contain the 2’s complement of the check-sum of the remaining interrupt vectors. This causes the checksum of all of the vectors together to be 0.
I know in my debug INI file I write to the MEMMAP location setting this to Flash but maybe this disassembly I'm seeing is the Boot rom?
Any thoughts?
Also, I'm new to the Keil environment as as the LPC family of chips so is this the best place to ask this type of question or is there a more LPC focused forum? (I didn't find any on a quick search)
I don't know about the ULINK Pro, but when downloading to flash from Keil + ULINK2, the reserved location in the vector table is programmed correctly. However, this is done "on the fly", this location is not calculated in the HEX-output from the compiler/linker. This means that if you program the flash yourself (for example with IAP) you will need to calculate this during programming (or pre-calculate it).
It also means that if you send away a HEX file to order pre-programmed chips, you must either ensure that the programming facility will calculate and program this location, or you must modify the HEX file so that this location contains the correct value. Guess how I know...
Thanks Øyvind,
That is what I thought. Do you have a good way to calculate this explicitly? For example do you use a script or a formula?
I don't know very well your device but it seems like it uses the same technique as how the hex file line checksum is done. In the intel hex file, if you add ALL the BYTES in a line it should result to zero (at least the lower byte is zero). The last byte of the line is in fact a number to make the sum equal to zero. Having not seen a sample of your hex file, I recommend you do bytes addition. If it does not work, try words addition. There are only a few lines in the vectors so doing manually on a calculator is easy.
Just add the hex bytes. For example, for brevity let's assume our vectors is only 3 lines where the 3rd line is the reserved: 1st line: E59FF018 --> E5h + 9Fh + F0h + 18h = 28Ch 2nd line: E59FF018 --> E5h + 9Fh + F0h + 18h = 28Ch Total sume of the 2 lines is 518h 3rd line: FFFFFAE8 --> this is a 2's complement of 518h. If you do 518h + FFFFFAE8 = (1)00000000
MV
I realized I switched to word mode to add the 3rd line which is probably incorrect (it is inconsistent with the byte add). So my guess is all words are added (instead of bytes). Unless, the device manual says the reserved line is prefilled with 00h. In which case it would have been 000000E8h, such that 518h + 00 + 00 + 00 + E8 = (6)00h.
For word add: 1st line: E59FF018 2nd line: E59FF018 --> Total sum of the 2 lines is (1)CB3FE030h 3rd line: 34C01FD0 --> this is a 2's complement of CB3FE030h. If you do CB3FE030h + 34C01FD0 = (1)00000000h
I'm just doing it in code. Add the 32-bit words of the other vectors together and calculate the two's complement of the sum. Then write this result to the reserved vector/location.