cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F072 Discovery as programmer

jesper
Associate II
Posted on January 23, 2015 at 10:27

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)

 
2 REPLIES 2
Posted on January 23, 2015 at 17:50

Not seeing any configuration code here to understand what might be happening. Be aware that the DISCO boards may provide an 8 MHz HSE signal without a crystal (ST-LINK via MCO (PA8)), so be conscious of your clock source and PLL configuration parameters, and the flash wait states.

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
jesper
Associate II
Posted on January 25, 2015 at 13:58

Thank you for the tip about the external clock on the DISCO board, but I have verified that this connection (SB19) is open on the F072B-DISCO.

I think I have found my fault, after a few days of frustration and head-against-the-wall-banging. I had the wrong value resistor soldered in for the BOOT0 pin, causing it to be pulled low weakly, which made the CPU rather unstable... Damned those 0603 chips :-).