• State Verified Answer
  • Replies 8 replies
  • Subscribers 69 subscribers
  • Views 6073 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 220250
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

How do I read my .map file?

Andrew Ong

I am trying to free up some RAM on my nRF because I am getting Fatal error 0x4, NRF_ERROR_NO_MEM when I try to increase the size of a 2D array. 

I do not understand how to read my map file. This is the file that contains all my symbols, correct? I sorted all the symbols by size and this is what I get: 

Apparently all the ".debug_str" take up 11 MB total? That's a lot but if it's all in flash then I don't care. I want to free up RAM. How do I list only the RAM symbols? Do I just delete the entire ".text" section from the .map file?

I filtered out all the ".debug" symbols and I'm left with this: 

First of all, what is the difference between ".bss.ucHeap" and ."heap"? 

Secondly, I changed my makefile to make the heap size = 0 and my stack size bigger (from 2048 bytes to 3072), but my application STILL Fatal errors with 0x04 when I try to increase the size of a 2D array from [2][75] to [2][140]. I am only using 130 more bytes in the array. Why can't my stack handle it if I just increased its size from 2048 bytes to 3072? I am not using malloc() anywhere. 

New map file after stack/heap modification: 

 

Parents
  • 0

    You should consider using objdump. I found it useful to dump all the symbols from the ELF file, sort or grep them by type (data, code, whatever), and then by size. In my case, I quickly realised that the heap reserved by the linker script was huge and unnecessary, and that the heap reserved by FreeRTOS was also huge. I've switched to static allocation for pretty much all objects as this means that the linker will complain long before I have to deal with runtime error codes.

  • 0 in reply to UnicycleBloke

    This was helpful. I didn't know ".bss.ucHeap" is the FreeRTOS heap. Mine was set to 8192. I lowered it to 4096 and FreeRTOS crashed. I lowered it to 8000 and FreeRTOS seemed to run, but then when I increased my array size from 140 to 280, I still got a runtime error NRF_ERR_NO_MEM even though I can see in the map file that my array is now 0x112 = 280 bytes as expected. So I'm not clear as to why disallocating 192 bytes and then reallocating 140 bytes causes a runtime error. 

Reply
  • 0 in reply to UnicycleBloke

    This was helpful. I didn't know ".bss.ucHeap" is the FreeRTOS heap. Mine was set to 8192. I lowered it to 4096 and FreeRTOS crashed. I lowered it to 8000 and FreeRTOS seemed to run, but then when I increased my array size from 140 to 280, I still got a runtime error NRF_ERR_NO_MEM even though I can see in the map file that my array is now 0x112 = 280 bytes as expected. So I'm not clear as to why disallocating 192 bytes and then reallocating 140 bytes causes a runtime error. 

Children
Related