stm32f411 bricked?

[uliano]

I can't connect under (hardware) reset with either ST-Link v3 and a cheap clone of J-Link v9.

Are there other options?

[barshatriplee]

Maybe just a bad chip...

[uliano]

it was working before but something went really bad during the last flashing: Windows seemed strange, after restart a few bluescreens some recovery and some disk check I got corrupted the WSL and all the softwares that are based on home directory such as vscode cargo and the like... .

I finally reinstalled all the software and regained access to the WSL so, given the premises, a $6 brick is not so bad... I was just wondering if there are other way out of curiosity.

[Psi]

You sure you have the boot pins set correctly

[uliano]

It's a black pill there are no boot pins, moreover I'm connecting through SWD.

(and doing nothing different than before or with the other black pill which works)

[darkspr1te]

It's a black pill there are no boot pins, moreover I'm connecting through SWD.

(and doing nothing different than before or with the other black pill which works)

Try to hold it in reset using the devices reset pin and then connect to it, in stcube programmer you must select manual reset and not software reset as that wont work if the chip is in protection mode.

darkspr1te

[uliano]

I did connect a wire from the NRST pin of stlink to the R pin of the blackpill believing that the hardware reset was provided by this wire.

However now I did also try to connect while pressing reset on the blackpill button. To no avail.

The setting is "hardware reset".

(fun fact: no matter how many times I do it, CubeProgrammer keeps suggesting me to upgrade my stlink v3 firmware)

[uliano]

Ok, second unit "bricked" (this one still runs the last firmware I loaded).

in BOTH cases it happened when I tried to experiment with wfi in the main loop. I start to feel a pattern...   

Is there something that I don't know that may possibly help me out of this?

For example I have NO IDEA about UPLOADING the firmware with USB with buttons BOOT & RESET as I always used an st-link/jlink for the purpose

[boB]

I don't suppose you could have secured the part using the highest level which can brick parts from programming, erasing and reading ?

Or, does the processor draw more 3.3V current than it should which could indicate a broken part ?

boB

[uliano]

At least the second unit is running the last firmware I uploaded. The problem is I can't connect with the debugger anymore.

[DavidAlfa]

It's impossible to brick a stm32. Make sure nRST is connected.
Some ST-Link clones have nRST wrong, connected to a wrong pin, thus not working.
Better to enable SWD in the code you're flashing so the interface is always active, avoding the requirement of nRST pin.

Anyways, you can manually do it:
- Connect SWD, Open ST-Link Utility.
- Short nRST to gnd or press button if available.
- Click connect on ST-Link Utility, wait 1-2 seconds, remove nRST short.
- Should recognize it. Erase it and it'll be ready.

[uliano]

@DavidAlfa   exactly what I was looking for (I recovered both units!)

(I am using an original St-link 3, so I doubt NRST is wrongly connected)

[peter-h]

It's impossible to brick a stm32

I read something that ST will not accept warranty claims on chips that have been secured with a certain level. I don't recall the details. What could that have referred to? If one could always erase the part, how could such a situation arise?

[DavidAlfa]

It probably refers to L2 protection, where the debug interface becomes permanently disabled.

[voltsandjolts]

So when you say "impossible to brick", do you mean even if L2 is enabled and the debug iface is broke?
In that case you can still use the bootloader?

[DavidAlfa]

I mean you can't accidentally brick it if the flash procedure fails , disconnects or something like that.
To enable L2 you must do it manually, then accept a warning message, that wouldn't be "accidental", right? 

[peter-h]

I must be mis-understanding but - having never done this - I thought you could enable L2 purely from any program. Page 93-94 in the RM describes this. It is irreversible. So if your code contains code to do that, it could be executed as a result of a crash. Probably one would want to have some sort of a hardware test in there e.g. holding down a button.

Level 1 is reversible but that forces a chip erase.

[AndyC_772]

Yes, you can enable L2 by setting the option bytes in your own code.

The other way to brick an STM32 is to set the BOR threshold to be higher than the supply voltage used on the board. I've done exactly this when porting code from a platform which ran the CPU at 3.3V to one which uses 2.5V.

The only way to recover the chip in this case is to increase its supply voltage somehow, so it can come out of reset and start responding to the debugger again.

[DavidAlfa]

I think my point was very clear, the common "bad flash" where something goes wrong.
Of course you can screw it up with wrong code!
Still, you might be able to overcome this with BOOT0=1 ?