Closed charlespax closed 8 years ago
The board is missing a pullup resistor on RESET. I added a 10k pullup and the board still did not work.
Are we writing to the correct memory locations? Maybe we're using the locations for a different device and we're stomping on settings or something. Here is the memory layout in mem.ld
MEMORY
{
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 20K
CCMRAM (xrw) : ORIGIN = 0x00000000, LENGTH = 0
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 64K
FLASHB1 (rx) : ORIGIN = 0x00000000, LENGTH = 0
EXTMEMB0 (rx) : ORIGIN = 0x00000000, LENGTH = 0
EXTMEMB1 (rx) : ORIGIN = 0x00000000, LENGTH = 0
EXTMEMB2 (rx) : ORIGIN = 0x00000000, LENGTH = 0
EXTMEMB3 (rx) : ORIGIN = 0x00000000, LENGTH = 0
MEMORY_ARRAY (xrw) : ORIGIN = 0x00000000, LENGTH = 0
}
You had a pullup on BOOT1 here but I think it should be a pull down for normal (i.e. flash) operation. Not that that should stop the ST-Link from detecting the chip - but the missing reset pullup may have. Is the ST-Link working now, but code not running? That could be BOOT1.
We're working with v0.1.1 boards right now, which have BOOT1 floating and BOOT0 toe to GND through a 10k resistor.
My understanding of the table below is that the device will boot into Main Flash Memory if BOOT0 is tied to GND, regardless of the status of BOOT1. Then if BOOT0 were high, BOOT1 would select between System Memory and Embedded SRAM.
]
The ST-Link programmers have no problem connecting to another development board we have (same chip family). I can connect just fine with fresh chips, but not after flashing them.
I'll go back an try some previous firmware and see if the same thing happens. If other code does not brick the boards, we'll have a good start to figuring out what specific software component (if any) is causing the problem.
Other possibilities:
OK, yeah I guess that is right - but I certainly wouldn't leave the pin floating. It is "don't care" when BOOT0 is pulled down, but it is still a CMOS input and can have problems if floating.
Here are some links to other similar reports & solutions that may help: http://electronics.stackexchange.com/questions/84921/is-it-normal-to-brick-the-stm32f0-with-certain-software-pin-configurations http://electronics.stackexchange.com/questions/204996/stm32-st-link-cannot-connect-to-mcu-after-sucessful-programming
Problem solved. It was the CAN bus stomping on another configuration.
The v0.1.1 board we have keep dying. I think it's some kind of configuration problem. It could also be something related to the boot mode pins. The ST-Link v2 debuggers are not able to connect to a board some time after being flashed.
Version 0.1.1 has SWO on PA15 when it should be on PB3 (SCK3 is on PB3).