Keil Disassembler - please explain output

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.

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.

Hi,

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.

M

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?

Hello,

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?

Hello,

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?

Thanks.

M