odd pin behavior (STM32F0) - Page 1
Forum section: electronics / general

author: old gregg
author_rank: Regular Contributor
timestamp: September 09, 2016, 05:27:03 pm
content: I've bought few stm32f030K6 for a project. I'm trying to flash them with the ST-link (via SWD protocol) utility from a STM discovery board.It doesn’t work but the more odd, is that the Reset Pin (NREST) is giving pulses and the SDWIO pin is giving a sawtooth. It does this alone, with no SDW protocol connectedI’ve soldered two of those processor and both responds the same.someone had the issue before ?

author: JPortici
author_rank: Super Contributor
timestamp: September 09, 2016, 05:45:30 pm
content: post the circuit schematic!SWD lines might require pullups/pulldowns

author: old gregg
author_rank: Regular Contributor
timestamp: September 09, 2016, 05:53:49 pm
content: I wrote SDW protocol because they are the pin associated with it. But it odes this on its own, with just the power on .

author: ataradov
author_rank: Super Contributor
timestamp: September 09, 2016, 06:00:41 pm
content: It may be normal, if SWDIO is driven by the device when reset is asserted. When device comes out of reset, the pin is switched to an input state and you see exponential fall of the voltage as parasitic capacitors discharge.

author: tatus1969
author_rank: Super Contributor
timestamp: September 09, 2016, 06:41:26 pm
content: have you checked the +3.3V supply rail? Could be repeated resets/restarts due to brownout.

author: old gregg
author_rank: Regular Contributor
timestamp: September 09, 2016, 07:29:46 pm
content: QuoteI've just checked the LOG file of the ST link program, is 2.9V low enough to cause a brownout ? the power is coming from the devboard, it's a bit late now but I'll try with a proper 3V3.Ok, I couldn't wait, I just checked with my power supply, at 3.3V, the reset pin stopped outputing pulses but the SWD communication is still not happing.

author: tatus1969
author_rank: Super Contributor
timestamp: September 12, 2016, 05:45:02 pm
content: you still need to connect your +3v3 to STlink, it needs it to sense I/O voltage levels.

author: old gregg
author_rank: Regular Contributor
timestamp: September 15, 2016, 05:09:12 pm
content: Hi,I finally made it work. It was the voltage not sufficient enough, you're right about the brownout. I also managed to get some code running and try to familiarize myself with the Keil debugger (which strangely can't set breakpoint in the C file but can't in "simulator" mode) .

author: tatus1969
author_rank: Super Contributor
timestamp: September 15, 2016, 08:23:21 pm
content: good to hearbreakpoints do work well in Keil, make sure to use debug build and disable all optimizations.

author: old gregg
author_rank: Regular Contributor
timestamp: September 20, 2016, 09:40:02 pm
content: Hi,I manage to get the debug part working in unchecking some option (download at debug I think) but it sometimes has weird behavior (I can't stop the processor).i downloaded the software pack from Keil for the stm32f030xx serie. The one I'm using is the stm32f030k6 (32kbit) but the flash algorithm used is the Flash\STM32F0xx_64.FLM and I can't change that even if the _32.FLM file is in the same folder. I've some memory issues that may be caused by it.

author: tatus1969
author_rank: Super Contributor
timestamp: September 21, 2016, 06:36:12 am
content: Quote from: old gregg on September 20, 2016, 09:40:02 pmsounds like SWI comms problem. Try reducing the clock speed in the debugger options for a test.

author: old gregg
author_rank: Regular Contributor
timestamp: September 23, 2016, 06:43:08 pm
content: actually it was my very messy setup that was causing (and still) troubles. One more reason to note why I hate breadboards. I need to learn how to properly use the debugger now.you've been of great help tatus1969, thank you !

author: tatus1969
author_rank: Super Contributor
timestamp: September 23, 2016, 07:32:00 pm
content: you're welcome!

author: old gregg
author_rank: Regular Contributor
timestamp: November 24, 2016, 04:55:11 pm
content: I still can't have a reliable connection between the stlink programmer on the devboard adn the external chip. Sometimes it does work not for long but lose the connection. The wirring is valid but the bloody thing connects to the MCU only when it wants to do so. The MCU is working fine though, blinking its led. It's very frustrating. I'm having the same issue with a STM32F103.However it works fine with the MCU on the devboard.does anyone have experience with that ?

author: thm_w
author_rank: Super Contributor
timestamp: November 24, 2016, 05:54:51 pm
content: Picture of board or schematic?Your BOOT pins are connected appropriately?

author: dgtl
author_rank: Regular Contributor
timestamp: November 24, 2016, 08:19:08 pm
content: Too long wires connecting SWD? Bad ground to stlink or ground loops? Keep in mind that SWD is pretty fast and is not differential, so it is quite delicate.Also, the code running on the uc can mess up connecting the debugger when running (ie if some low-power state is entered and required clocks are off, muxes swd pins etc). If you mess up your code so that the swd is unusable and you can't connect anymore, try putting the uc to bootloader mode with boot0 pin and after that connect to it with swd. Then you can re-program the code and recover.

author: ealex
author_rank: Frequent Contributor
timestamp: November 24, 2016, 10:11:54 pm
content: i've had problems with cable cross talk - 2-3 loops trough a ferite toroid worked as a temporary fix.also, be very careful when you use PORTA - the SWD pins are there (PA13 / 15 ?? ) and you can disable it from your code.

author: AndyC_772
author_rank: Super Contributor
timestamp: November 24, 2016, 10:56:56 pm
content: It sounds like it might be a signal quality issue. Can you post a picture of the physical board layout and wiring?

author: Jeroen3
author_rank: Super Contributor
timestamp: November 25, 2016, 02:17:50 pm
content: Reasons debug might misbehave:1. The incorrect image is loaded in the mcu. (eg: "download to flash" tickbox is off with debug)2. Too many breakpoints. iirc, max 4. Otherwise "run" won't work anymore.3. The GPIO initialisation remaps or reconfigures the SWDIO and SWDCLK ports. Make sure to explicitly init ALL GPIO ports.4. The DBGMCU->CR is default so that you're kicked out on standby/sleep/stop. Change it.5. The link is bad, lower the speed.