Keil Disassembler - please explain output

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

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

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

MV

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.