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
What is strange with loading PC with the address of the interrupt vector service routine?
So you have one table with load instructions.
And a second table with the addresses of the real routines.
Note the distance between the instructions in the first table - with 4 byte for the LDR PC,xx instructions, you can't fit a full 32-bit target address there.
Hi,
Thank you for your comment.
I do understand the assembly. It's the dis-assembly I don't understand. For example if a Pre-fetch Abort occurs and the PC is reset to 0x0000000C I don't understand how it will jump to the appropriate handler. Could you maybe explain the dis-assembly?
Assembly:
LDR PC, Reset_Addr LDR PC, Undef_Addr LDR PC, SWI_Addr LDR PC, PAbt_Addr LDR PC, DAbt_Addr NOP ; Reserved Vector LDR PC, [PC, #-0x0120] ; Vector from VicVectAddr LDR PC, FIQ_Addr Reset_Addr DCD Reset_Handler Undef_Addr DCD Undef_Handler SWI_Addr DCD SWI_Handler PAbt_Addr DCD PAbt_Handler DAbt_Addr DCD DAbt_Handler DCD 0 ; Reserved Address IRQ_Addr DCD IRQ_Handler FIQ_Addr DCD FIQ_Handler Undef_Handler B Undef_Handler ;SWI_Handler B SWI_Handler PAbt_Handler B PAbt_Handler DAbt_Handler B DAbt_Handler IRQ_Handler B IRQ_Handler FIQ_Handler B FIQ_Handler IMPORT SWI_Handler
Dis-Assembly:
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 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 0x00000040 EAFFFFFE B 0x00000040 0x00000044 EAFFFFFE B 0x00000044 0x00000048 EAFFFFFE B 0x00000048 0x0000004C EAFFFFFE B 0x0000004C 0x00000050 EAFFFFFE B 0x00000050 0x00000054 EAFFFFFE B 0x00000054
Thanks again.
M
Looks weird indeed. Have you checked the output of the assembler, e.g. is the assembler generating the correct opcodes?
Someone else had the same problem back in 2008, the comments of the posters are very cryptic, though.
" as the first instruction in cases where the reset handler was close enough to be reached by a direct branch. You could try that and see if it straightens out the assembler.
Andrew
I created a new project, using the default "LPC2400.s", and an empty main(). Tested with the KEIL Simulator, My Disassembly Window showed something different:
1054: Vectors LDR PC, Reset_Addr 0x00000000 E59FF018 LDR PC,[PC,#0x0018] 1055: LDR PC, Undef_Addr 0x00000004 E59FF018 LDR PC,[PC,#0x0018] 1056: LDR PC, SWI_Addr 0x00000008 E59FF018 LDR PC,[PC,#0x0018] 1057: LDR PC, PAbt_Addr 0x0000000C E59FF018 LDR PC,[PC,#0x0018] 1058: LDR PC, DAbt_Addr 0x00000010 E59FF018 LDR PC,[PC,#0x0018] 1059: NOP ; Reserved Vector 1060: ; LDR PC, IRQ_Addr 0x00000014 E1A00000 NOP 1061: LDR PC, [PC, #-0x0120] ; Vector from VicVectAddr 0x00000018 E51FF120 LDR PC,[PC,#-0x0120] 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: 0x0000001C E59FF018 LDR PC,[PC,#0x0018] 0x00000020 00000058 DD 0x00000058 0x00000024 00000040 DD 0x00000040 0x00000028 00000044 DD 0x00000044 0x0000002C 00000048 DD 0x00000048 0x00000030 0000004C DD 0x0000004C 0x00000034 00000000 DD 0x00000000 0x00000038 00000050 DD 0x00000050 0x0000003C 00000054 DD 0x00000054 1073: Undef_Handler B Undef_Handler 0x00000040 EAFFFFFE B 0x00000040 1074: SWI_Handler B SWI_Handler 0x00000044 EAFFFFFE B 0x00000044 1075: PAbt_Handler B PAbt_Handler 0x00000048 EAFFFFFE B 0x00000048 1076: DAbt_Handler B DAbt_Handler 0x0000004C EAFFFFFE B 0x0000004C 1077: IRQ_Handler B IRQ_Handler 0x00000050 EAFFFFFE B 0x00000050 1078: FIQ_Handler B FIQ_Handler 1079: 1080: 1081: ; Reset Handler 1082: 1083: EXPORT Reset_Handler 1084: Reset_Handler
I suggest to check the hex or lst file. I'm guessing you showed the run-time disassembly which may have been corrupted when the CPU bombed out due to undecodeable instruction. There is no reason R4 - R6 should be involved in the vectors area.
I think you are right. The listing file looks ok. Any suggestions on how to debug this bomb out? It happens consistently.
Basically the problem I'm having is setting up my project (LPC2478 - Olimex board) so that I can use the external SDRAM but initialize the SDRAM from code so that my application runs on a reboot and not just from a debug session where the SDRAM is initialized from an INI file.
Thanks.
A few things can happen: 1.) A mixture of ARM and Thumb and it bombed out in Thumb. 2.) I may have seen that problem before when you scroll up the disassembly window during a C debug. It generates disassembly according to what data is available at the time. Maybe you are in Thumb and happen to scroll up and the debugger got confused as other codes are ARM.
Also note that when you let the compiler generate the literal pool (as most people do), you will see 0's in that area on the lst. The hex file would show the actual data.
MV
Is the listing you're showing in RAM or flash, e.g. could it be that the SDRAM is not set up correctly and reads back incorrectly? I've seen that happen with bad SDRAM parameters but I assume you're showing the beginning of flash memory. In that case it's hard to imagine how the contents would get corrupted.
What's the disassembly look like right after you load the code but before you run anything?
This is from internal flash (address 0x0 on this device). The disassembly looks like this immediately after download and before running anything.
I am using Thumb mode as the default and this section of the startup file is indeed marked ARM. Shouldn't the disassembler know the difference?
If I want to use the external SDRAM what is the general strategy in terms of the linker settings (scatter file) and the initialization from code being executed before the SDRAM is initialized?
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.
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?