search

PaxInstruments / labwiz-board

A development board based on the STM32 series processors specifically targeting the STM32F103RxT series.
4 stars 2 forks source link

Screwy boards #33

Closed charlespax closed 8 years ago

charlespax commented 8 years ago

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.

screen shot 2016-08-03 at 21 19 26 screen shot 2016-08-03 at 21 19 12

Version 0.1.1 has SWO on PA15 when it should be on PB3 (SCK3 is on PB3).

charlespax commented 8 years ago

The board is missing a pullup resistor on RESET. I added a 10k pullup and the board still did not work.

charlespax commented 8 years ago

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
}
electrokean commented 8 years ago

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.

charlespax commented 8 years ago

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. 6c4c93e6f0708beb3983928cc9450171198cac16]

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.

charlespax commented 8 years ago

Other possibilities:

electrokean commented 8 years ago

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

charlespax commented 8 years ago

Problem solved. It was the CAN bus stomping on another configuration.