Issue debugging on an STM32f105

[Deamonata]

Hi there,

I'm not sure if I've encountered a bug or if I'm doing things wrong so I'll describe what I'm trying to do and where it's going wrong. My eventual goal is to have a python script that I can call from another tool (using a cli inteface) which can program a given elf file onto an STM32F105 and then run it for a period of time, after 30 second I then want to pause the micro and then read back an array from the RAM.

I've written ascript that I believe to be correct I'm obtaining the address for the start of the array from the elf file using get_symbol_value() and then reading the data, because the array has a known end pattern I've set it up to keep reading until the known end pattern is found.

When I tested this on an STM32F429 my script worked correctly and I was able to recover the data, however when I ran the script against the STM32F105 the data that I pulled back was incorrect. After some debugging I found the data within the memory but at the wrong address. according the the map file the data should have started at 0x20000068 and been 0x400 bytes long. Instead the data seems to be located at 0c2000fbd0. In the image below I've captured some of the data:

It looks like all the data is offset from where I would expect and I have no idea why. Currecntly my best guess is that it's an issue with the CMSIS pack but I'm honestly at a bit of a loss. do you have any better ways of doing what I'm trying to do or any suggestions on where to look in the CMSIS pack to validate it against the datasheet?

[Deamonata]

digging further, the first variable in the RAM should be SystemClock which should be set to 16,000,000, I found this at 0x002000fb68, which is 0x68 bytes before the array i was looking for. This means that it appears that the entire RAM contents has been shifted up by 0xfb68 bytes. I have no idea what could be causing this though. The only other bit of information I have located is that the value at the start of the RAM (0x20000000, where SystemClock should be) is 0xdeadf00d which looks like some sort of marker.

George