0

I'd like to see how much RAM is used by the firmware by writing a known pattern, and comparing RAM contents to see how much has been modified.

I've tried

reset halt
load_image pattern.bin 0xaddress
resume
(let target run for a bit)
halt
dump_image sram.bin 0xaddress 0xsize

but it appears I have obtained flash contents and cannot see the test pattern anywhere. Am I using the proper commands? If I "verify" manually by loading and dumping, the data is identical. Could halt affect the RAM contents? Otherwise, is it safe to assume that the application in fact initializes all of the RAM, making analysis difficult/impossible?

I should point out that I only have a "dump" of the firmware, i.e. I am not building it.
handle
  • 5,859
  • 3
  • 54
  • 82
  • Could you provide the exact reference for the Cortex-M3 you are using, for example ST Microelectronics STM32F103C8T6 ? this would help figuring out which exact addresses should be used in the `load_image`/`dump_image` commands. – Frant Feb 20 '20 at 16:00
  • The map file produced by the linker can tell you how much RAM is being used by your program. – kkrambo Feb 20 '20 at 19:09
  • what does your linker script look like where is .text, .data and .bss? for RAM usage you want to examine the ram not just the .text area but all of it. – old_timer Feb 20 '20 at 19:13
  • @kkrambo I'm not building the firmware. – handle Feb 20 '20 at 19:22
  • @Frant Thanks, but the addresses were not the issue. – handle Feb 20 '20 at 19:23
  • how are you writing a known pattern if you are not building the code? didnt write bootstrap code to fill ram, etc? start with some very simple 10 or so line of asm programs, get to know the openocd tools, then move on to more complicated things. – old_timer Feb 20 '20 at 20:46
  • what chip are you using? – old_timer Feb 20 '20 at 20:47
  • @old_timer I am writing the pattern to RAM using OpenOCD. I do not have any source code for the device. I did not mention the part number because this is more about the general approach with OpenOCD and I was not able to find much on the internet. – handle Feb 21 '20 at 08:07
  • but you know it is a ram based program and not flash based like normal? – old_timer Feb 21 '20 at 09:14
  • if not your program then why examine ram usage? – old_timer Feb 21 '20 at 09:15
  • @old_timer No, I don't know if and how much of the firmware runs from RAM. I wanted to examine the RAM usage to see if there is some unused memory available. – handle Feb 21 '20 at 09:41
  • if it wont execute because you are running it in the wrong place then that experiment wont/cant work. What does the first handful of words of the binary look like? what are their values (in hex of course) – old_timer Feb 21 '20 at 15:37

1 Answers1

0

I had to do soft_reset_halt to get the PC to the reset vector address. My version of OpenOCD warns me that the command is deprecated. Then I was able to spot a few occurrences of my test pattern in the RAM dump. Also, there are notable differences between the RAM image and the firmware, so it seems that the firmware is indeed using most of the RAM.

(this might not be an issue if your interface is using a physical reset line?)

handle
  • 5,859
  • 3
  • 54
  • 82
  • if you build for the mcu, .text will be in ram a copy of .data that you copy to ram and .bss you zero in the bootstrap. so most of ram will not be the program, in general. but there are exceptions. there is a reason why mcus have more flash than ram usually – old_timer Feb 20 '20 at 19:14
  • @old_timer - I'm not building the firmware. – handle Feb 20 '20 at 19:22
  • if you are using a physical reset line then .text goes in flash, etc...and I wrote that wrong... – old_timer Feb 20 '20 at 20:41
  • per your question about a reset line, .text a copy of .data and where and how much .bss will be in flash. the bootstrap copies .data and zeros .bss. So most of ram will not be the program, in general. but there are exceptions. there is a reason why mcus have more flash than ram usually – old_timer Feb 20 '20 at 20:42
  • you can resume 0xaddress, if you use the elf file then you dont need 0xaddress on the load image line its in the binary. technically it should be resume 0xaddress|1. the binary has to be built to run in ram vs run in flash from a reset, two different entry point/methods. (or the soft reset thing) – old_timer Feb 20 '20 at 20:45