Error: failed to erase memory

ABouk · ‎2019-08-15

Good afternoon, I was trying to debug a program on my new stm32f103C8T6 chip using the st-link v2 programmer, but i always get the same error : Error: failed to erase memory

I have tried the procedure with multiple boards so i guess that the problem is software, here is the full console output :

STMicroelectronics ST-LINK GDB server. Version 5.2.3

Starting server with the following options:

Persistent Mode : Disabled

Logging Level : 1

Listen Port Number : 61234

Status Refresh Delay : 15s

Verbose Mode : Disabled

SWD Debug : Enabled

Waiting for debugger connection...

Debugger connected

-------------------------------------------------------------------

STM32CubeProgrammer v2.1.0

-------------------------------------------------------------------

Log output file: /tmp/STM32CubeProgrammer_k3pQvR.log

ST-LINK SN : 33FF6D064E59343942520343

ST-LINK FW : V2J33S7

Voltage : 3.20V

SWD freq : 4000 KHz

Connect mode: Under Reset

Reset mode : Hardware reset

Device ID : 0x410

Device name : STM32F101/F102/F103 Medium-density

Flash size : 63.999 MBytes

Device type : MCU

Device CPU : Cortex-M3

Memory Programming ...

Opening and parsing file: ST-LINK_GDB_server_JSWBJu.srec

File : ST-LINK_GDB_server_JSWBJu.srec

Size : 9716 Bytes

Address : 0x08000000

Erasing memory corresponding to segment 0:

Erasing internal memory sectors [0 9]

Error: failed to erase memory

Encountered Error when opening /Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.macos64_1.0.0.201904021149/tools/bin/STM32_Programmer_CLI

Error in STM32CubeProgrammer

Error! Failed to read target status

Debugger connection lost.

Shutting down...

Thanks !

Jack Peacock_2 · ‎2019-08-15

"Flash size : 63.999 MBytes"

WOW! Where do I get an STM32 with 64MB of internal flash????? And it's only medium density?

Looks like you're trying to erase far more memory than what's installed. You'll hit a hard fault at the end of real memory.

Jack Peacock

ABouk · ‎2019-08-15

It is written in the data sheet that the stm32f103c8t6 got 64/128 Kb flash I think i negliged the Mb unity, can you tell me how can i fix it ?

ABouk · ‎2019-08-15

When i write the .elf file in the flash, i get "stlink_fwrite_flash() == -1" ...

Can someone help me with those flash problems please ?

Bob S · ‎2019-08-15

You might try updating the STLinkV2 firmware. There is at least a version V2.J34M25 available. Also, have you checked the option bytes to see if any sectors/pages are write protected? Though I would expect an error message from STCubeProgrammer saying so if that were the case.

Is this a custom board, or one of the Nucleo/Discovery boards? I'm guessing from your "I have tried the procedure with multiple boards" comment that this is a custom board. If that is case, check the power supplies, bypass capacitors and reset circuit.

ABouk · ‎2019-08-15

I have updated my stink v2 firmware to V2.J34M25, and no i didn't check that option, im getting the same error
Yes it's a custom board, the reset circuit is a pull-up 10k resistor + 100nf ceramic capacitor, and the power is provided by an ams1117-3.3v so it's safe.

I tried to use the st-flash command in terminal, here what i get :

Bob S · ‎2019-08-15

Something is seriously messed up!

That terminal session shows that the programmer thinks there is 25616 KBytes of FLASH (as mentioned above). And apparently your program is 705348 bytes (688 KBytes). All targeted to a CPU that really only has 64KBytes of FLASH.

So first, find out why your program is so HUGE.

Maybe the ID value that is being returned isn't valid? Look in the reference manual this CPU and see what the ID is supposed to be. Look for the DBGMCU_IDCODE register.

Hmmmm... the FLASH size may be reported by the chip itself, if the debugger is reading the "Flash size data register". This should report 0x040 for 64KBytes. So maybe the debugger connection to the chip is flakey? Or the chips are somehow messed up.

I wonder if trying to erase pages way above the actual FLASH memory region has somehow broken the CPUs? I would hope this isn't the case.

And "power is provided by an ams1117-3.3v so it's safe". That isn't necessarily so. If you don't have all the power pins connected, or you have bad solder joints, or insufficient bypass capacitors, or the power supply feeding the 3.3V regulator is somehow current limiting. Check your schematic against the closest Nucleo/Discovery board that you can find.

ABouk · ‎2019-08-15

I have found a way to generate the bin file, it's only 4572 bytes but im getting the same problem ...

Im sure that the problem is software because i reviewed the pcb layout many times and tested solder points, resistors, capacitiors ...

Here is what i'm getting when i try to burn the 4.5 Kb in the chip's flash

Bob S · ‎2019-08-15

Have you tried to read the option bytes? You may need to go back to the CubeProgrammer to do that.

Maybe look at the SWD signals on a scope. Make sure they are clean, good edges and good signal levels.

The device ID value looks reasonable for your the F103 part. Though I would still be worried about the irrational value that both CubeProgrammer and st-flash are both reading for the FLASH size. It may be a case of both of them reading the (same) wrong memory address (kind of strange coincidence). Or it may be an indicator that the chips are really not behaving as they should and maybe the flash size register isn't the only thing that isn't working right.

ABouk · ‎2019-08-15

I have changed the wires for SW communication, still same result.

I don't think it's random value for the flash size, else i would have different value every time i reprogram the flash memory.

And I'm sorry but i don't know how to read the options bytes, still new in stm ...