On 15 Feb 2005 at 13:50, Robert Adsett wrote:
>
> At 06:53 PM 2/15/05 +0200, Anton Erasmus wrote:
> >IThe section after the uart0Puts works. When I press a key on the
> >serial terminal, it is echoed correctly back. So it seems that the
> >baud rate etc. is correct. If I compile the code with no optimisation
> > (Default is set to O2), then it prints the "Hello World!" as
> >expected. If I add a uart0Putch('U') before the uart0Puts, the U is
> >printed. If I add more, then sometimes the "Hello World!" is printed
> >correctly. I have looked in the hex file generated, and the ASCII
> >data is put in the .rodata section as expected. It looks as if the
> >ASCII strings are aligned at 4 byte boundaries, so I do not think it
> >is an alignment problem. Has anyone else had problems with literal
> >strings using gcc 3.4.3 ? Any suggestions on where I can look to find
> >the problem would be appreciated.
>
>
> Just a thought (I haven't tested 3.4.3) but this looks what you would
> expect if constant data wasn't being referenced correctly. IE ld was
> placing the data in flash and expecting it to be copied to RAM (and
> the startup wasn't expecting the constant area to have to move). Have
> you checked your link script?
>
> Of course that leads to the question of why the link script changed,
> but I can see misplacing it.
>
I am using the linker script supplied with the example code. The assembly code looks
fine for all optimisation levels. The ASCII data is defined and put in the .rodata section
which is placed in the text section just after the code. The assembly is typically:
ldr r0, =LC0
with LC0 being the label of a word.
LC0 .word LC1
where LC1 being the label of the ASCII data.
The ldr pseudo instruction is then transformed into a number of instructions.
Unfortunately I do not have JTAG debug capability at the moment, so it is a bit
difficult to see what the actual run-time calculation is. The dissasembler is also not
smart enough to spot references to defined word such as at the LC0 label, but tries to
dissasemble the value. It does not look as if the .rodata section should be copied to
RAM for it to work. Also the fact that it works correctly with no optimisation. If it was a
problem with data not being copied to RAM when it should be, then I would expect it to
fail with no optimisation as well. I am beginning to suspect that the conversion of the ldr
pseudo instruction to actual code might be incorrect. AFAIK the compiler will try and
calculate the address, and only if it cannot do so actually read the address from a
defined word with a PC relative load. It might be that it is failing when it can calculate
the address. Anybody here know what the assembler actually does with a ldr pseudo
instruction ?
Regards
Anton Erasmus
--
A J ErasmusMessage
Re: [lpc2000] Problem with GNUARM 3.4.3
2005-02-15 by Anton Erasmus
Attachments
- No local attachments were found for this message.