Dealy bug (?) in CM0 microlib

Building with Microlib:

    s_tx_buffer                              0x100015d0   Data        2050  bluetooth_frame_handler.o(.bss)
    STACK                                    0x10001dd8   Section      304  startup_lpc11xx.o(STACK)

"s_tx_buffer" goes until 0x10001DD2 - but the stack grows backwards...?
This causes data corruptions - of course!

withuot Microlib:

    s_tx_buffer                              0x100015cc   Data        2050  bluetooth_frame_handler.o(.bss)
    .bss                                     0x10001dd0   Section       96  libspace.o(.bss)
    HEAP                                     0x10001e30   Section        0  startup_lpc11xx.o(HEAP)
    STACK                                    0x10001e30   Section      304  startup_lpc11xx.o(STACK)
    Heap_Mem                                 0x10001e30   Data           0  startup_lpc11xx.o(HEAP)
    Stack_Mem                                0x10001e30   Data         304  startup_lpc11xx.o(STACK)

Which looks better and indeed causes no corruptions.

 RE: Dealy bug (?) in CM0 microlib

What's a Dealy bug?

"s_tx_buffer" goes until 0x10001DD2 - but the stack grows backwards...?
This causes data corruptions - of course!

Why of course?

What is the SP initialised to? It's not uncommon to set it to the TOP of the section.

 RE: Dealy bug (?) in CM0 microlib

Wait a minute - let's get this straight: Are you saying you are cool with a linker than causes data corruption in your programs (no ridicule intended - honestly) ?
Let's let Keil decide...

 RE: Dealy bug (?) in CM0 microlib

But exactly what is the problem?

Your array starts at 0x100015d0 and first free address is then 0x10001dd2.
Your stack starts at 0x10001dd8 and first free address is then 0x10001f08.

So there is a 6-byte gap between your array and the stack. Not so strange since the stack has special align requirements.

When looking at a dump of memory regions, it doesn't matter if the stack grows up or down. You still normally dump the memory regions by specifying the lower address.

For a processor where the stack grows towards higher addresses, you use this start address of the stack memory region when initializing the stack pointer.

For a processor where the stack grows towards lower addresses, you base the initialization of the stack pointer on the end of this stack region. Either by making use of the start address and size. Or by having a dummy segment reference directly following the stack.

Your dump doesn't show any error. But maybe your startup code does something stupid when initializing the stack pointer.

The build without microlib will have the first free byte above the stack at address 0x10001f60, so it consumes a bit more memory. But neither of the dumps shows any information that indicates any memory overlap.

 (no ridicule intended - honestly)

OMG. Are you telling us you've put in a report to Keil support?

I can only assume that you passed them some evidence that actually shows a problem instead of something you're misinterpreting.

I'd say that you simply didn't set the stack size to cover what was actually required.

But as you say: Let's let Keil decide...

 RE: (no ridicule intended - honestly)

I'd say that you simply didn't set the stack size to cover what was actually required.

I hope so - but it's weekend!

 RE: (no ridicule intended - honestly)

I hope so - but it's weekend!

That was last weekend. Still no reply. Now what?

 Where is the 'delete post' button when you need it?

Now what?

LOFL

Keep quiet, lie low, hope everybody forgets the post ever existed???

 RE: Dealy bug (?) in CM0 microlib

Are you saying you are cool with a linker than causes data corruption in your programs

What on earth gave you the idea that anyone so much as hinted at anything as silly as that?

 RE: Dealy bug (?) in CM0 microlib

This causes data corruptions - of course!

Wrong. What you've shown does not cause any data corruption just like that, much less does it "of course" do so.

Which looks better

Specifically, please: how do you think that looks any better? What's the supposedly significant difference you see between

a) 304 bytes of stack following almost immediately after the .bss section of one module, and

b) 304 bytes of stack following immediately after the .bss section of some other module,

and why do you expect it to prevent any data corruption in case b) that case a) exhibited?

and indeed causes no corruptions.

You're rather certainly wrong about that. Odds are you've just not noticed the corruption in that case yet --- because there's really no reason in the facts you've shown that would allow to concluse that it would be any less likely.

 I hope so - but it's weekend!

Weekend's over.

Don't keep us on tenterhooks. What have you found?

 RE: I hope so - but it's weekend!

Any updates?

 The relentless passage of time

Any updates?

 You think we'd forgotten?

Any news? Keil update of serious linker bug imminent?

 Fixed in 4.23?

Update for MDK-ARM released two days ago.

http://www.keil.com/download/product/

No doubt, a rush release to fix the Dealy linker bug.

But wait. No mention of it in the release notes.

Jeez, must be a tough one for the Keil development team to fix!?

 RE: Fixed in 4.23?

i get a error in link. u got fix????

 RE: Fixed in 4.23?

i get a error in link. u got fix????

Maybe the OP will give us an update on that nasty Dealy bug?