2015-09-28 02:27 AM
Hey everyone. I've just put together my first STM32F7 LQFP100 breakout board. I wanted to first try the STM32F7 Discovery board, but the camera connector doesn't support the OV5645.
I'm having trouble uploading flashing through SWD (I'm using a Segger JLINK, which keeps saying ''No device found on SWD''). I've successfully created and used a similar board based on the STM32F437VG before. The documentation said the pin out should be identical with the STM32F4, except for the bottom and left side rows, which I've changed.How can I go about debugging this? I've already checked connectivity of all the power, VCAP, BOOT0, reset, and SWD pins.Also, I'm not certain that the chip has the right orientation. The STM32F4 had a marker to show which corner was pin 1. Somehow the STM32F7 has 2 markers which is confusing (figure 80 in the manual still says pin 1 is at the bottom left corner when you orient the text correctly which is consistent with what I did for STM32F4).Thanks for your help #stm32f72015-09-28 04:19 AM
Hi zhang.yale,
Yes you are right; the pin 1 is at the bottom left corner.Regarding the other pins connections (mainly debug ones), I recommend you have a look to : Getting started with STM32F74xxx/STM32F75xxx MCU hardware development. You find there a section about ''Debug Management''.If you refer to , the figure 1 shows incompatibility between LQFP100 packages of both F4 and F7 devices.Hope these 2 application notes bring you some help.-Mayla-To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2015-09-28 01:36 PM
Thanks, I'm looking at the reference design and see several differences with my board:
*no individual filter capacitors on each adjacent VDD VSS pin. I use a combined 20uF cap. for the whole bus - my board is a single layer board and can't afford to be that robust.*VBAT, VREF+- not connected*no resistor on BOOT pin - I just wire it directly to VSS.Are these show stoppers?I'm starting to think the chip is bad or there are shorts created by left over solder paste (I used a soldering iron, which doesn't melt and clump all the paste. I later cleaned it with alcohol and a Q-tip but there still might be some left)What about the built in boot loader that lets you flash through I2C, USART, SPI, etc (application note 2606)?Is there an application I can install to use it (like Flash Magic, which works for NXP MCUs) ?Maybe I shouldn't have jumped so soon to building my own board. I can try it again on a Schmart Board.2015-09-28 01:53 PM
Flash Loader Demonstrator is what STM32 parts normally use, but you can just as easily get signs-of-life sending an 0x7F at 9600 8E1 via RealTerm.
STM32 use the analogue supplies for the POR, and PLL/VCO side of things, not sure how that plays with VREF if the pins aren't bonded to the analogue side.2015-09-30 04:43 AM
LOL - signs of life. I've found it. I'm measuring lots of neural activity, um I mean SWD in the 3V range.
So, what I did to debug the problem was to wire up the same circuit on a Schmart Board which should be more reliable. This time I connected VBAT & Vref+, and used a resistor instead of wire for BOOT to be safe. But SWD didn't work either. Manually soldering 0.5 pitch pins is inherently error prone and I had to reflow several flaky solder joints. I checked connectivity of the SWD pins using a DSO Quad oscilloscope. Then I changed the BOOT pin to 1 instead of 0, and then it miraculously started working. Switching BOOT back to 0 broke SWD again. I don't remember what I did at this point, probably reflow a few joints and wiping away soldering residue. After that, BOOT = 0 finally started functioning.Wary of the soldering issues I encountered, when I tried my breakout board again, I soldered the SWD connections instead of using jumper wire connectors. This seemed to pay off and I now have a working board. Note, I did not have to connect VBAT or Vref+.My tentative conclusion is that flaky solder connections caused my problems. It seemed the BOOT pin had something to do with it, but I think that was just a manifestation of bad soldering.2015-09-30 01:10 PM
Yes, the STM32's are notoriously difficult to see if they are alive or dead when just statically powered, in days of yore you could see oscillators kick on, or boot loaders chirp, here you have to physically kick it.
Electrically the things to look at are the state of the NRST/NRESET pin, and the VCAP pins for the internal regulator kicking on. I think the biggest circuit gotchas are the analogue supplies, and regulator bypass, and leaving the BOOTx pins floating.