AnsweredAssumed Answered

STM32F072 Discovery as programmer

Question asked by we.jesper on Jan 23, 2015
Latest reply on Jan 25, 2015 by we.jesper
I have just gotten the PCB for my first STM32-based design, using a F072CBT6 chip. The board is only populated with the power regulator and the CPU with its surrounding passive components.

I have the F072 Discovery board, which I am trying to use as a programmer for the new design. The program so far is just a skeleton app generated by STM32CubeMX.

I am using Keil uVision 5.13, and I have flashed the latest ST-LINK/V2 firmware onto the F103 chip which is the programmer on the discovery board.

If I flash my code onto the target chip on the discovery board (it is a 64 pin rather than my designs 48 pin chip, but that shouldn't matter I would think...) my code runs fine and I am able to stop, step and debug it using uVision.

Using the STM32 ST-LINK Utility program I am able to connect fine to the CPU on my new board, and to erase the chip, so basic SWD operations work fine.

I can also download my program to the CPU using Keil uVision without problems, it flashes and verifies OK.

But if I try to run the program on my target under uVision, or if I try to debug and single-step it, the debugger looses contact with the target. It is OK up the the point where the code sets up the clocks (The HAL_RCC_OscConfig() call), but then it disconnects.

Since I can run the exact same code on the discovery board target without issues, I figure it must be some hardware problem on my board. First I suspected cabling, since I could see a fair bit of ringing on SWCLK and SWDIO, so I cut down the cables between the discovery board and my target to 150 mm. The signals now look good, but the problem persists.

The only other thing I can think of is to do with the 3.3V power. My board has a high performance LDO regulator with proper decoupling, nice fat routing of VDD/VSS to the CPU, and X7R decoupling capacitors according to the hardware design manual, so power stability should not be the issue.

But the programmer runs on 3.0V rather than my targets 3.3V. Could this be the cause???

There is a VDD_TARGET pin of the programmer board, but it seems not to be in use. Resistor R15 is not mounted, so there is no routing of the VDD_TARGET to the AIN_1 input. I looked at connecting it, but I am unsure how it is supposed to be connected???

As shipped, the programmer has the built-in target VDD connected to AIN_1, over a /2 voltage divider. Obviously this needs to be disconnected. The external VDD_TARGET input instead has (when R15 is bridged) a diode in series, which will give forward voltage drop. So disconnecting the internal target VDD and connecting the external one will give totally different readings on AIN_1. This makes me unsure about how to proceed.

Any advice on this would be much appreciated!!
(Or other tips on what could cause my target to loose it connection at clock setup)


 

Outcomes