Could not determine SRAM entry point

[picman1877]

Hi I have an STM32F103RET6 Device connected to serial port COM10 Waiting for debug probe to be connected... Debug probe connected to STM32F1 target STM32F1 target is confirmed to be read protected

Traceback (most recent call last):
  File "C:\stm32f1\dump.py", line 428, in <module>
    sram_entry_point = get_sram_entry_point()
                       ^^^^^^^^^^^^^^^^^^^^^^
  File "C:\stm32f1\dump.py", line 269, in get_sram_entry_point
    raise Exception("Could not determine SRAM entry point\nopenocd output: " + line)
Exception: Could not determine SRAM entry point
openocd output: xPSR: 0x01000000 pc: 0x1ffff020 msp: 0x200001fc

The date Code is 133 Is this a newer chip?

[MIGINC]

I am getting the same error, with a new chip STM32F103C6T6A date code 223 I moved into a bluepill board.

Did you have any success?

[picman1877]

No sorry..

[CTXz]

I've been receiving quite a few issues regarding the SRAM entry point in the recent weeks. I'm currently a little short on time so I appologize for the lack of responses.

Based on the PC value of 0x1ffff020, your STM does not appear to be configured properly to boot into SRAM, but instead boots for "system memory" (aka. bootloader mode).

RM0008 P.60-62 Section 3.4 talks about this:

Depending on the selected boot mode, main Flash memory, system memory or SRAM is
accessible as follows:
 - Boot from main Flash memory: the main Flash memory is aliased in the boot memory space (0x0000 0000), but still accessible from its original memory space (0x800 0000). In other words, the Flash memory contents can be accessed starting from address 0x0000 0000 or 0x800 0000.
 - Boot from system memory: the system memory is aliased in the boot memory space (0x0000 0000), but still accessible from its original memory space (0x1FFF B000 in connectivity line devices, 0x1FFF F000 in other devices).
 - Boot from the embedded SRAM: SRAM is accessible only at address 0x2000 0000.

This hints that your BOOT0 pin is being set correctly to 1 by the pico but your BOOT1 pin is not registering a 1. Please double check if your BOOT1 pin is being pulled up correctly. If necessary, take a reading of the voltage at the pin.

[picman1877]

OK, that got me further(RTFM), thank you.. now i'm here...

Waiting for Pi Pico to be connected... (Looking for COM11)
Device connected to serial port COM11
Waiting for debug probe to be connected...
Debug probe connected to STM32F1 target
STM32F1 target is confirmed to be read protected
Detected SRAM entry point offset: 0x1e0 (0x200001e0)
Please select the USART used by the STM32F1 target to dump firmware
1: USART1 - RX: PA10 TX: PA9
2: USART2 - RX: PA3  TX: PA2
3: USART3 - RX: PB11 TX: PB10
Enter 1, 2 or 3: 1
Press enter to load the target exploit firmware to the SRAM

Target firmware loaded to the SRAM
Waiting for debug probe to be disconnected...
Warning: Disconnect the debug probe from the target, not just the host USB port!
Debug probe disconnected from STM32F1 target

Attack ready
Press enter to start dumping firmware

Timeout: No data received from target
Please consult the README for troubleshooting steps

README dosen't seem to contain that error.. I am using uart1 PA10 and PA9 and only have the "target_1e0_usart1.bin" in the target dir. And yes the uart is connected the correct way round.. Seems to upload the firmware OK, so not sure where i go from here...

[CTXz]

It's difficult to say what's failing here. The question is whether the STM even boots into the exploit firmware. Do you have the equipment (ex. an oscilloscope or logic analyzer) to see if there's any output on the STM's USART TX (PA9)? If you don't have access to such equipment I'd quickly write a test firmware that blinks the bluepill's internal LED before starting the dump. That way it'd at least confirm that it's entering the target exploit firmware.

EDIT:

Also, the README does contain information regarding timeout errors. See the troubleshooting section. That being said, I suppose you have already taken a look at it?

EDIT2:

One more thing. It seems like you're running this on Windows (based on the fact that you're talking about COM ports). I've unfortunately not tested the dump script under windows and the README also hints that a Linux machine should be used. If you have access to a Linux device it'd be cool to test it out on one just to eliminate that as a possible cause for the issue.

[picman1877]

OK, Got it working by leaving the debugger connected, and starting stm32cubeprogrammer and connected it after it said remove the probe, not sure why this works, but it did... I do have a full Elctronics Lab. Might be the Pico is not pulling the reset back high.. This is not connected to a blue pill, its connected to a board from work where we needed the code from a chip that got lost.... Anyway thanks for your help, and all good now....

One weid side effect was i think the code in the SRAM rapped around and i got this from the output: !! EXCEPTION !!! ID: 03 Restart required!

pages and pages of it, it never stopped...

[CTXz]

Glad you got it working somehow, albeit with some quirks :)

Since you've managed to dump the code successfully, I'll close this issue now.

Cheers!