--- In l..., "Donald H" wrote:

> Richard,
>
> How did you calculate one word at the top ??
>
> don
>

Am I wrong?

I am assuming two things: First, the address is a byte address and, second, that when the stack is pushed, it writes the first data byte to the byte address below the current address. That is, the stack is 'full descending' in ARM notation.

So, if the address is 0x40003FFC, the first byte pushed will go to 0x40003FFB. This leaves bytes 0x40003FFC..3FFF (4 bytes - 1 word) unused.

If I am wrong, please let me know.

Richard

Start a New Thread

--- In l..., "rtstofer" wrote:
>
> --- In l..., "Donald H" wrote:
>
> > Richard,
> >
> > How did you calculate one word at the top ??
> >
> > don
> > Am I wrong?
>
> I am assuming two things: First, the address is a byte address and, second, that when the stack is pushed, it writes the first data byte to the byte address below the current address. That is, the stack is 'full descending' in ARM notation.
>
> So, if the address is 0x40003FFC, the first byte pushed will go to 0x40003FFB. This leaves bytes 0x40003FFC..3FFF (4 bytes - 1 word) unused.
>
> If I am wrong, please let me know.
>
> Richard
>

The stack does grow down.

At the first stack push or call a 32 bit address is written to the stack address, which would be 3FFC-3FFF, and then it it decremented to 3FF8.

don

Start a New Thread

Hi don,

On Mon, Dec 14, 2009 at 15:58, Donald H wrote:
>
> The stack does grow down.
>
> At the first stack push or call a 32 bit address is written to the stack address, which would be 3FFC-3FFF, and then it it decremented to 3FF8.

Let's check what the ARM manual says:

"Push Multiple Registers stores multiple registers to the stack,
storing to consecutive memory location
ending just below the address in SP, and updates SP to point to the
start of the stored data."

And here's the pseudocode:

if ConditionPassed() then
EncodingSpecificOperations();
address = SP - 4*BitCount(registers);
for i = 0 to 14
if registers == 1 then
if i == 13 && i != LowestSetBit(registers) then
MemA[address,4] = bits(32) UNKNOWN;
else
MemA[address,4] = R[i];
address = address + 4;
if registers<15> == 1 then
MemA[address,4] = PCStoreValue();
SP = SP - 4*BitCount(registers);

As you can see, the values are written below the SP value. So yes, one
word gets "wasted" when SP is set to xxxxFFFC.

--
WBR, Igor
Start a New Thread

>
> As you can see, the values are written below the SP value. So yes, one
> word gets "wasted" when SP is set to xxxxFFFC.
>
> --
> WBR, Igor
>

But there are variations on the STMxx instruction. There is pre and post pointer modification as well as grow up/down (increment/decrement).

The STMFD instruction is of the pre-decrement, grow down variety.

So, I still see this as wasting a word. There may be a perfectly valid reason for doing so. I know there are some reserved addresses for IAP and ISP. I have never bothered to rationalize whether to actually reserve them or not. I just do...

But I dont' use IAP and ISP occurs before my code gets control so I'm not really sure I need to reserve anything.

As to the top of stack: given the predecrement operation, I would be inclined to set the value at 0x40004000 and not waste any space.

And I would still put the irq stack above the user stack.

One of the problems of grabbing code from here and there is that you don't know what assumptions were made when it was written. That, and you have no idea who wrote it and whether they even had a clue about what they were doing. Mixing code from various chips is likely to lead to hours of troubleshooting.

I think it is wise to be very skeptical of code you don't personally write. Regardless of the source...

Richard

Start a New Thread

Hi richard,

_stack_top = 0x40003FFC;
_irq_stack_top = 0x40003BFC;
with above values, i tried.i am not getting data on to hyperterminal.i attached my file which is in the folder name "LPC2129_UART".
--- In l..., "rtstofer" wrote:
>
> >
> > As you can see, the values are written below the SP value. So yes, one
> > word gets "wasted" when SP is set to xxxxFFFC.
> >
> > --
> > WBR, Igor
> > But there are variations on the STMxx instruction. There is pre and post pointer modification as well as grow up/down (increment/decrement).
>
> The STMFD instruction is of the pre-decrement, grow down variety.
>
> So, I still see this as wasting a word. There may be a perfectly valid reason for doing so. I know there are some reserved addresses for IAP and ISP. I have never bothered to rationalize whether to actually reserve them or not. I just do...
>
> But I dont' use IAP and ISP occurs before my code gets control so I'm not really sure I need to reserve anything.
>
> As to the top of stack: given the predecrement operation, I would be inclined to set the value at 0x40004000 and not waste any space.
>
> And I would still put the irq stack above the user stack.
>
> One of the problems of grabbing code from here and there is that you don't know what assumptions were made when it was written. That, and you have no idea who wrote it and whether they even had a clue about what they were doing. Mixing code from various chips is likely to lead to hours of troubleshooting.
>
> I think it is wise to be very skeptical of code you don't personally write. Regardless of the source...
>
> Richard
>

Start a New Thread

--- In l..., "raju" wrote:
>
> Hi richard,
>
> _stack_top = 0x40003FFC;
> _irq_stack_top = 0x40003BFC;
> with above values, i tried.i am not getting data on to hyperterminal.i attached my file which is in the folder name "LPC2129_UART".
Hyperterminal will embarrass you. I have had MANY projects where the UART worked fine but Hyperterminal didn't display properly.

Sometimes quitting and restarting Hyperterminal will help.

HOWEVER, your startup code is wrong! In the loop do_init, you are copying from an initialized area inside .text (and I have NO IDEA what might be in that section, GCC doesn't use it) instead of copying all of the .data section.

Easiest change:

initdata_start: .word __initdata_start__

initdata_end: .word __initdata_end__
becomes

initdata_start: .word __data_start__

initdata_end: .word __data_end__
Or you could clean up the whole thing (get rid of the 'init...' stuff entirely).

I would remove the .initdata block within .text. I have no idea how it could be used.

Richard

Start a New Thread

The option -mhard-float is probably wrong. I don't think the lpc2129 has hardware floating point.

Richard

Start a New Thread

Hi richard,

I executed the same file which is there in LPC_2129UART folder with LPC2148(with changes only stack setting in linkerscript and no changes in start up file).it is working fine and getting data on to hyperterminal.
--- In l..., "rtstofer" wrote:
>
> --- In l..., "raju" wrote:
> >
> > Hi richard,
> >
> > _stack_top = 0x40003FFC;
> > _irq_stack_top = 0x40003BFC;
> >
> >
> > with above values, i tried.i am not getting data on to hyperterminal.i attached my file which is in the folder name "LPC2129_UART".
> Hyperterminal will embarrass you. I have had MANY projects where the UART worked fine but Hyperterminal didn't display properly.
>
> Sometimes quitting and restarting Hyperterminal will help.
>
> HOWEVER, your startup code is wrong! In the loop do_init, you are copying from an initialized area inside .text (and I have NO IDEA what might be in that section, GCC doesn't use it) instead of copying all of the .data section.
>
> Easiest change:
>
> initdata_start: .word __initdata_start__
>
> initdata_end: .word __initdata_end__
> becomes
>
> initdata_start: .word __data_start__
>
> initdata_end: .word __data_end__
> Or you could clean up the whole thing (get rid of the 'init...' stuff entirely).
>
> I would remove the .initdata block within .text. I have no idea how it could be used.
>
> Richard
>

Start a New Thread