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.
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!
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?
That was last weekend. Still no reply. Now what?
Now what?
LOFL
Keep quiet, lie low, hope everybody forgets the post ever existed???