Bricked?

[izua]

Posted on October 17, 2010 at 16:56

Hello,

I seem to have bricked my board. I have been experimenting with different compilers and linkerscripts, and probably something was messed up. None of the three IDEs will to establish contact with the board. The ST-Link utility which can flash binary files to the chip won't let me flash anything, saying that readout protection is active. If I try to remove readout protection from the ST-Link utility, it just hangs. (LE: and after 5-8 minutes it errors ''cannot set option bytes: please reset the device and try again'') If I remove the readout protection via USART, it says it's successful, but again I'm not able to flash anything via ST-Link. As you might know, the USART flashing tool from ST doesn't have any data for stm32f100, so you can't flash/read the chip from it. I have also tried this on linux, using stm32loader.py and a

http://code.google.com/p/stm32flash/

. Using a binary I have tested earlier, that flashes the two on-board leds, I have flashed the board over USART using the two tools mentioned above. Each time, after flashing, I have reset the board and set BOOT0 to logic 0, but the program won't start anymore. The communication protocol over USART seems ok though, I've even tried reading the chip ID and supported commands manually and it works. The ST-LINK chip also seems to work, since the 30MB drive with the three files is created. My initial suspicion was that some runaway code disable JTAG, but that would have been solved by erasing the chip over USART. The only modifications to the board are removing PB10-PB15 so it can fit in a breadboard, and removing the BOOT0 jumper (J16 iirc, not sure) so I can use the USART bootloader. Anyone experience this before? Thanks

[Tesla DeLorean]

Posted on October 17, 2010 at 18:44

Are you sure the binary you are programming actually works? ie known to work, or golden, code. Have you tired the main.bin file attached to the previous GNU/GCC thread?

Not surprised that the ST serial flash programmer doesn't support it, as the serial port isn't exported to a connector, and it's physically bonded to an ST-LINK. The source is however open so it could be added. And the protocol is documented. ROP is a pig to disable for sure. The USART1 method and JLink STM32 application were the most workable for the STM32F103. Can you read out code via the USART1? How about downloading and running code in RAM? The chips are very difficult to brick, I'd suggest you check the power supplies and clocks,  but you appear to be able to communicate with the boot loader so it's clearly still alive.

[izua]

Posted on October 17, 2010 at 19:49

Yeah, I still haven't found a method of bricking the chips in theory (probably because the availability of several flashing methods), so I started suspecting that when inserting the board in the breadboard, a pin was broken from a pad or a trace was interrupted.

So I started looking for such an issue and having found none, I put the discovery module back in the breadboard and then I saw some mismatching connections 🙂 Hardware trouble, after all. Yes, the firmware at that point was a vanilla/'golden' one, as you say, I always keep one around, just in case. I have also succeeded in running the one from you, and also compiling the one from you and running my compiled version. Thanks!