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.
What's a Dealy bug?
Why of course?
What is the SP initialised to? It's not uncommon to set it to the TOP of the section.
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...
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.
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...
I hope so - but it's weekend!
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.
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?
Weekend's over.
Don't keep us on tenterhooks. What have you found?
Any updates?
That was last weekend. Still no reply. Now what?
Now what?
LOFL
Keep quiet, lie low, hope everybody forgets the post ever existed???
Any news? Keil update of serious linker bug imminent?
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!?
i get a error in link. u got fix????