Reply by raju December 14, 20092009-12-14
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
>

An Engineer's Guide to the LPC2100 Series

Reply by rtstofer December 14, 20092009-12-14
The option -mhard-float is probably wrong. I don't think the lpc2129 has hardware floating point.

Richard

Reply by rtstofer December 14, 20092009-12-14
--- 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

Reply by raju December 14, 20092009-12-14
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
>

Reply by rtstofer December 14, 20092009-12-14
>
> 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

Reply by Igor Skochinsky December 14, 20092009-12-14
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
Reply by Donald H December 14, 20092009-12-14
--- 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

Reply by rtstofer December 14, 20092009-12-14
--- 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

Reply by Donald H December 14, 20092009-12-14
--- In l..., "rtstofer" wrote:
>
> --- In l..., Raju N wrote:
> >

I am not interested in Raju Ns homework problem.

> > On Sun, Dec 13, 2009 at 1:24 AM, rtstofer wrote:
>
> You can get the memory map from Figure 2 of the User Manual
>
> I'm not sure why they are leaving 1 word at the top of RAM, but what's one word?
>
> _stack_top = 0x40003FFC;

Richard,

How did you calculate one word at the top ??

don

Reply by rtstofer December 13, 20092009-12-13
--- In l..., Raju N wrote:
>
> Hi richard,
>
> thank u,
>
> _stack_top = 0x40007FFC;
> _irq_stack_top = 0x40007BFC;
> Can u tell me,what are the values i need to set here for lpc2129 which 256k
> flash and 16k RAM?
>
> On Sun, Dec 13, 2009 at 1:24 AM, rtstofer wrote:

You can get the memory map from Figure 2 of the User Manual

I'm not sure why they are leaving 1 word at the top of RAM, but what's one word?

_stack_top = 0x40003FFC;
_irq_stack_top = 0x40003BFC;

So, they're putting the irq stack 1k below the regular stack. Seems like that isn't much stack for user programs but I haven't looked at the startup code to see what they are doing.

Were it me, I would put the irq stack at the top of memory becuse interrupt routines don't generally have a lot of local variables to push on the stack. I would have the user stack underneath the irq stack.

But that's a refinement. It's unlikely these values will cause a problem in the beginning.

Richard