• AVR Freaks

Hot!PIC32MZ1024EFE064 - cannot use all RAM

Author
boatbodger
Junior Member
  • Total Posts : 108
  • Reward points : 0
  • Joined: 2011/03/27 15:39:07
  • Location: 0
  • Status: offline
2020/05/23 11:20:12 (permalink)
0

PIC32MZ1024EFE064 - cannot use all RAM

This device has 256k of RAM.  I need to allow multiple HTTP connections and they gobble heap like its going out of fashion
My static data requirement is about 30k bytes, IDE says I have 233512 bytes free, but if I try to create a heap 160,000 bytes (which I need for 8 HTTP connections, it seems), the linker says "Error: Not enough memory for heap (160000 bytes needed, 155444 bytes available)".
The linker script correctly states total RAM at 0x40000 bytes.I have called up a stack size of 10,000 byres (decimal)
 
Any ideas where I could start to look?
I have attached the map file.  .ld script is unmodified stock script
 
Thanks in advance
post edited by boatbodger - 2020/05/23 11:27:17

Attachment(s)

Attachments are not available: Download requirements not met
#1

7 Replies Related Threads

    andersm
    Super Member
    • Total Posts : 2798
    • Reward points : 0
    • Joined: 2012/10/07 14:57:44
    • Location: 0
    • Status: offline
    Re: PIC32MZ1024EFE064 - cannot use all RAM 2020/05/23 15:51:53 (permalink)
    0
    Are you using the address attribute or something else that could fragment the address space?
    #2
    simong123
    Lab Member No. 003
    • Total Posts : 1391
    • Reward points : 0
    • Joined: 2012/02/07 18:21:03
    • Location: Future Gadget Lab (UK Branch)
    • Status: offline
    Re: PIC32MZ1024EFE064 - cannot use all RAM 2020/05/23 17:50:14 (permalink)
    0
    Looking at the map file there is a huge (76k) hole between 0x80002cfc and 0x800160f0 (printfBuff) apparently not allocated, hence there is not a large enough contiguous space for your heap requirements. I see nothing in the default linker scripts to cause this.
    I have never seen anything like this before. I would raise a support ticket.
    In the mean time I would look to decreasing the HTTP buffer sizes, if possible.
    #3
    boatbodger
    Junior Member
    • Total Posts : 108
    • Reward points : 0
    • Joined: 2011/03/27 15:39:07
    • Location: 0
    • Status: offline
    Re: PIC32MZ1024EFE064 - cannot use all RAM 2020/05/24 00:57:49 (permalink)
    0
    I spotted that hole having slept on the problem overnight!
    This morning, i rebuilt using production, not debug, and the hole disappeared.
    Any reason Debug would need to reserve 76k of data space?  Seems a lot...
     
    I will look to see if the amount of data each http connection uses can be reduced, but it is a pretty hideous beast, and easily broken (I wove websockets handling into it and that nearly killed me...)
    #4
    boatbodger
    Junior Member
    • Total Posts : 108
    • Reward points : 0
    • Joined: 2011/03/27 15:39:07
    • Location: 0
    • Status: offline
    Re: PIC32MZ1024EFE064 - cannot use all RAM 2020/05/24 02:03:38 (permalink)
    +1 (1)
    Aha - I think I know what this might be - NO - WRONG - SEE NEXT POST
    Several different (mchip) modules use a static char[] array named printBuff and I have seen instances before where the linker goes bonkers if the same static name is used in different modules.
    Last time I fell foul of this, the linker had used the same RAM for all those variables, on that occasion causing mysterious over-writing of DMA descriptors.
    This time it is just at risk of corrupting debug output, which is far less disruptive but still bad.
    And causing mis-allocation of RAM is doubly bad.
    Assuming it is "legit" (if questionable) practice to use the same name for static variables in different source files in the same project, this is a definite linker bug and I will raise a ticket.  (My knowledge of the "C" standard is practical rather than academic)
     
    I will go through renaming these variables in tcpip_commands.c, sys_debug.c and sys_command.c and report back.
    post edited by boatbodger - 2020/05/24 08:41:57
    #5
    boatbodger
    Junior Member
    • Total Posts : 108
    • Reward points : 0
    • Joined: 2011/03/27 15:39:07
    • Location: 0
    • Status: offline
    Re: PIC32MZ1024EFE064 - cannot use all RAM 2020/05/24 08:41:24 (permalink)
    +1 (1)
    I was wrong:
    sys_command.c uses static char printBuff[]
    sys_debug.c uses static char printBuffer[]
    and tcp_commands.c uses char printBuff[] but as a local array in a subroutine, i.e. on the stack.
    So there remains the mystery as to why the allocator skips about 76k of RAM when allocating 0x2000 bytes for sys_command.c > printBuff[]
     
     
    #6
    NKurzman
    A Guy on the Net
    • Total Posts : 18667
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: offline
    Re: PIC32MZ1024EFE064 - cannot use all RAM 2020/05/24 08:51:01 (permalink)
    0
    Does printfBuff[] have any attributes on its declaration?
    Is there anything related to the midpoint address of the ram? May be related to the upper half being coherent?
    #7
    boatbodger
    Junior Member
    • Total Posts : 108
    • Reward points : 0
    • Joined: 2011/03/27 15:39:07
    • Location: 0
    • Status: offline
    Re: PIC32MZ1024EFE064 - cannot use all RAM 2020/05/24 09:07:26 (permalink)
    0
    Thanks for the suggestion.
    The declaration has SYS_CMD_BUFFER_DMA_READY after it, but that is #defined as nothing.
     
    from syscommand.c:
    static char printBuff[SYS_CMD_PRINT_BUFFER_SIZE] SYS_CMD_BUFFER_DMA_READY;
     
    from configuration.h:
    #define SYS_CMD_PRINT_BUFFER_SIZE          8192
    #define SYS_CMD_BUFFER_DMA_READY
     
    Given the lack of content in the #define, I assuming no attributes would have been signalled through to the linker?
     
    #8
    Jump to:
    © 2020 APG vNext Commercial Version 4.5