• State Not Answered
  • Locked Locked
  • Replies 16 replies
  • Subscribers 22 subscribers
  • Views 3673 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Dealy bug (?) in CM0 microlib

Tamiryan Michael

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.

Parents
  • 0 in reply to Tamiryan Michael

    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.

Reply
  • 0 in reply to Tamiryan Michael

    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.

Children