Please consider some professional embedded system with 16-bit microcontroller.  

I know embedded software build tools report program flash memory usage.  I think they also report RAM usage but do they report maximum RAM usage?

Build tools may not know how much heap will be used during run-time.  Are there other RAM usages that build tools aren't aware of?

How to accurately find out how much RAM is being used during run-time?

First, if you statically allocate memory and don't use dynamic memory allocation, you should be able to figure out your RAM usage during compile time.

This can be done in several ways:

1) Reviewing your map file

2) Using your IDE's build-in tools to calculate the RAM usage. 

3) You can get stack depths etc using a static analysis tool. Although they will often miss pointers to functions so you have to be careful. 

Thank you! It's helpful.

I'm sure there are tools to report the maximum task stack usage in AutoSAR OS.  I don't know if the average AutoSAR app uses any dynamically allocated memory from the heap at all - typically in safety-critical  applications it is frowned upon. MISRA Rule 18-4-1 gives some guidance on the use of dynamic allocations -"Dynamic heap memory allocation shall not be used."  

There are plenty of memory profile tools available for that purpose in the non-automotive world.

Stack usage tends to be the most problematic since the same functions can act different depending on the call tree depth. Your platform may have tools, but I found this one works well for me since I mainly use gcc. The process does have limitations, but usually finding the most problematic code is fairly obvious. A little sloppiness can really snowball unexpectedly, and this will help you see how.  

https://github.com/PeterMcKinnis/WorstCaseStack

Static data allocations are the easiest. The linker/loader can accurately tell you the size of the const (often named '.data') and variable (often named .bss) sections.

Heap is managed by malloc() and friends, typically from a memory pool allocated by the linker/loader. That's the 'max'; any attempt to malloc more should return a null pointer. To get a general empirical idea of how much of the memory pool is actually used, fill it with 0xFF at startup and use calloc() instead, which will clear any allocated memory to zero. Exercise all the code paths, stop the program and count how much 0xFF memory is left. An accurate value requires static code analysis, either by tooling or by hand.

Like the heap, stack is typically pre-allocated. Unlike the heap, code will happily push off the end of the stack and into dragon-land. Zeroing the stack space at startup, exercising as many of the code paths as possible, stopping the program and examining the stack memory to see how much zeroed stack space is left is an empirical way of determining stack usage. Again, static code analysis is required for better accuracy. (And, as the other posters note, even static code analysis can miss stuff.)