STM32F103C8T6 Serial dump does not stop

[MoeBenMtl]

Hello I would like to thank you for sharing this utility and also ask a question about an issue I am having I have an STM32F103C8T6 Rev X
the process works fine but when I get to the serial dumping part it keeps dumping data forever ... if anyone has an idea please let me know

[CTXz]

Are you sure it's dumping forever? The script dumps a total of 128KB's of flash (even on 64K devices) at a baudrate of 9600. That should equate to almost 2 minutes of dumping. I'll confirm if it indeed does dump forever once I got access to my test setup. Perhaps the last target firmware update broke something and I've not tested it enough...

[MoeBenMtl]

I had the same reflection, I left it dumping until it reached 2048kb file size which made no sense.

[CTXz]

I can't say for sure until I've tested, but perhaps it enters a loop where it resets after receiving a out-of-bounds memory access induced hardfault, which in return jumps back to the start of stage 1.

Try the following traget binaries and let me know if they fix the issue:

target_firmware_v1.3.1tar.gz
Minor correction: target_firmware_v1.3.1v2.tar.gz

If this still doesn't do it, I'll take a closer look at this tommorow.

[MoeBenMtl]

Same outcome loops forever past 128kb also does seem to be in some sort of loop as the data that's being printed looks repetitive

[CTXz]

Alright, I'd just like to confirm that this is related to the latest release. Would you mind trying the last release?

https://github.com/CTXz/stm32f1-picopwner/releases/tag/a1.2_t1.2

Make sure to use the dump script from that release as well.

[MoeBenMtl]

I wiped and used last release and I have the same exact issue. Even tried a 2nd F103C8T6 Rev X.

[MoeBenMtl]

here's the dump

[CTXz]

Huh, that's rather interesting. It appears that this issue is unique to your set-up then.

I'll see if I can implement a condition in the dump.py script tommorow that rejects incoming data after the connected device's flash size has been dumped. Or at the very least, I'll add a flag that can restrict the dump file size to a provided size. That way, even if such an endless loop occurs, the script will still complete the dump.

[MoeBenMtl]

Alright, Ty also doesn't the data looks like it's dumping the same thing over and over ?

[CTXz]

Wups, I didn't pay enough attention to the image. I had assumed it's looping at the stop of the flash. You're right, in this case the proposed solution obviously won't be very useful. It seems to be looping after transmitting 404 bytes. It's also clearly resetting, as the start magic 0x10ADDA7A is being transmitted at the start of every repeat. Something must be triggering a reset.

I'll upload a couple of test firmware binaries later that could further diagnose what's potentially causing the issue. If you have an oscilloscope, perhaps you could monitor the reset line and see if it experiences some sort of voltage flunctuations that could cause the reset to trigger. If that's not an option, a multimeter reading of the NRST pin could also potentially help. That being said, the reset being triggered at exactly 404 bytes makes a wiring related issue less likely.

[MoeBenMtl]

You are right RST keeps getting triggered on original pcb nrst is tied to 3.3v

[CTXz]

Ok, I've come up with a workaround that should be able to dump despite experiencing resets.

Please use the following attack and target fimrwares and let me know how things look this time:

target_firmware_v1.3_rst_Workaround.tar.gz
attack.zip

The latest dump.py should be used

Note: The workaround works by storing its incremented address as a global variable. That way, the device is able to continue dumping where it last left off. That being said, since we still don't know the root cause of the rst triggers, this code could be prone to race conditions which could potentially lead to occasional duplicate or invalid data. The dump will also run significantly slower since the magic is being sent after every word is transmitted to hopefully reduce errors in case a unexpected reset does happen. The device is also now being forced into a reset after each tranmission. This isn't really necessary but allowed me to test if this workaround works.

[MoeBenMtl]

Amazing ! Ty will try in a bit and report

[MoeBenMtl]

Omg ! This worked mint ! Thank you !

[CTXz]

Sweet! In this case I'll close the issue now.

Cheers!

[deividAlfa]

Regarding this:
The options bits might be enabling the watchdog by default, this will cause unexpected reset, explaining this endless loop.
Made a PR for this: #25.

I recently discovered clones/fakes report no flash size (Flash size register=0xFFFFFFFF).
This will cause up to 64MB to be dumped, but shouldn't be a concern because accessing unimplemented memory should cause hard fault and inmediately stop the transfer, jumping into alertCrash.

In fact, we could just skip the flash size check and just keep writing until crashing?