Custom PCB STM32F756 'No MCU Found' IAR Error? - Page 1
Forum section: electronics / general

author: Boscoe
author_rank: Frequent Contributor
timestamp: August 21, 2016, 06:31:08 pm
content: Hi there everyone,I have an issue and wondering if someone on here could give me a hand.I have implemented an STM32F756 on a PCB of my own. I have connected everything correctly (I think) however I can't connect to it using ST-LINK having the error in the title. Attached is the schematic. I have gone through the pins on the PCB CAD and the STMCube software to make sure everything is correct. I'm trying to program it from IAR using code generated by STMCube with the system setting as SWD, PA13 and PA14 and NRST. I have measured the voltages on the pins and they are correct (VSS is 0V and VDD etc is 3V3).The schematic is attached.Any advice would be greatly appreciated.

author: jmsigler
author_rank: Regular Contributor
timestamp: August 21, 2016, 11:10:11 pm
content: I normally use a J-Link for st programming, so I'm not 100% on this, but does st-link need 3.3v input?

author: Korken
author_rank: Regular Contributor
timestamp: August 22, 2016, 06:05:29 am
content: Why do you have BOOT0 with a cap? I am also using the same MCU and copied the discovery board design, and it worked on the first try.Maybe try to remove it?You can also try to connect using OpenOCD to get some usable errors.

author: stj
author_rank: Super Contributor
timestamp: August 22, 2016, 06:30:58 am
content: i agree, those 2 caps will cause a tiny delay as they charge - they shouldnt be there.

author: Boscoe
author_rank: Frequent Contributor
timestamp: August 22, 2016, 06:36:52 am
content: Thanks guys I'll try removing them. They were originally there because I was going to include a jumper on the BOOT pin to enable manual entry to the system boot loader but I didn't want to add it in the end.

author: Kjelt
author_rank: Super Contributor
timestamp: August 22, 2016, 08:36:06 am
content: Long time since I went through this.Have you got it working with some other board like a development board?One of the issues that I ran into with the same error was the configuration of the debugger hardware.Depending on which programmer you use you can change the interface settings to jtag or swd depending on the hardware connection you made.Then you have to set the CPU and SWO clock and set reset to normal. It is the easiest to start with a ready built dev. board and get that running.Another reason could be the power to the cpu, we usually provide that power independent of the programmer since some can not supply enough juice.Also try first to connect the programmer and use the programmers own software to program the uC, for instance if you use STLINK first try to make the STM32 Link utility to work with the CPU to readout the memory contents. You can configure it there also for jtag or swd etc. get that working and then write down the settings and change them in IAR options.

author: tatus1969
author_rank: Super Contributor
timestamp: August 22, 2016, 01:35:57 pm
content: BOOT0 should be always low to let the micro start with your application in flash. But unless you already have flashed some code, I assume that it is still empty. But all this is only relevant if you want to flash code using DFU. If you plan to always flash the device via SWD, then you can directly tie that pin to GND.SWD is always available (independent from BOOTx) unless it is being disabled from your application code (be careful with that, since that can lock up the micro :-)Your STlink header is lacking the 3.3V supply. It depends on what programmer you have, but many of them have VDD sensing, and need to be able to probe the target board's supply voltage for level translation. My guess would be that it works after you add another lead for VDD, going to the STlink.Also, these devices have an internal power supply supervisor that generates a proper reset sequence when VCC ramps up. Your RC at the reset pin is not necessary, you can try leaving that pin unconnected. This also helps the STlink reset the micro, which would otherwise not be possible.

author: Pack34
author_rank: Frequent Contributor
timestamp: August 22, 2016, 07:43:24 pm
content: Quote from: Boscoe on August 22, 2016, 06:36:52 amActually, you want a capacitor between BOOT0 and ground, in parallel with the pull-down. This will let you trigger DFU mode using firmware. You set BOOT0 as a GPIO output, set it high, and then call NVIC_SystemReset() and it'll boot into DFU mode so you can update the firmware over USB.If you do not care about updating the firmware over USB then you can forget the capacitors all together.

author: tatus1969
author_rank: Super Contributor
timestamp: August 22, 2016, 08:31:50 pm
content: Quote from: Pack34 on August 22, 2016, 07:43:24 pmafaik you can trigger DFU directly from your code