ST-Link and the STM32F4 Discovery

[gabriel]

Posted on February 06, 2014 at 01:21

Hi Everyone,

Sorry if this is a repeat post, I'm pretty sure I've looked through all of the past discussions related to this and still have not found a solution.I designed a new board using the STM32F427 and have been unable to program the device using the external ST-Link V2 hardware via SWD or JTAG. I'm simply using the ST-Link Utilities on a windows 7 machine. I can connect to the device, read its ID/revision, read the program memory and erase it, but as soon as I try to program the device the ST-Link Utility disconnects with the following error:Internal command errorCannot connect to the device!I've noticed that this also erases the program memory (since I can program it via the USB boot loader).Now on to why I posted this in the STM32 Discovery section …Since this is my own board design I figured, hey lets try this on the STM32F4 Discovery to make sure I didn't mess up the design. Sure enough I have the same exact problem when I try to flash the discovery board using the SWD header (CN2) which bypasses the ST-Link chip on the discovery board.Early on I was unable to even talk to the F427 on my board until I updated the firmware of the ST-Link V2. This leads me to believe there is a firmware issue on the ST-Link.I found some old posts stating the ST-Link firmware was incompatible with rev Z of the STM32F407, but that it had been fixed. I did not see anything about this in the current errata sheets.The software I am loading is very simple (flash an LED). I am not changing any of the GPIO settings for the pins related to the SWD or using any of the sleep functions.Last, I've connected SWDIO, SWCLK, NRST, one 3.3V line and one return line of the ST-Link to the discovery board. I have not connected SWO as it should not be needed - I will give that a try though.Thanks for any suggestions.

[Tesla DeLorean]

Posted on February 06, 2014 at 01:46

You upgraded the firmware to what version?

Injecting SWD into a STM32F4-DISCO board is problematic, you have to make sure you break a bunch of solder bridges so the on-board ST-LINK does not interfere. CN2 is NOT a good injection point, for SWCLK and SWDIO the F4 side of CN3 would be better.Don't connect 3V supplies, just the GND

[gabriel]

Posted on February 06, 2014 at 18:36

Hi Clive,

Thanks for your reply.I updated the ST-LINK firmware to version V2.J17.S4 which is later than the version ST has in their firmware release notes.I see what you mean about bypassing the ST-LINK on the discovery board. I misunderstood - apparently the SWD header (CN2) is meant to allow you to use the discovery board as an ST-LINK for other hardware.I don't need to use an external ST-LINK on the discovery board, I was just troubleshooting my hardware. Now this post is in the entirely wrong area …Anyway, it just seems weird that I can use the external ST-LINK to do everything short of flash my own board (I can get the device ID/revision, read and erase). I must be missing something fundamental about SWD or have an issue with my hardware.Any other thoughts?Thanks

[Tesla DeLorean]

Posted on February 06, 2014 at 18:55

Yes, I grasped what you were doing.

The DISCO boards are a low cost ST-LINK for third part boards, I'm not terribly keen on them for that purpose, or the non-standard header(s). Using external debuggers on the DISCO boards also isn't a simple as it might be.I understand you were trying to cross-check your design/function with a second DISCO, smart move.I don't really have an insight into your board design, not much detail to work with here.For flashing problems I guess I might focus on supplies, and bulk-capacitance, which supply the charge-pump/voltage-generator for the flash programming circuits. You'd want to check the VCAPx pins. Perhaps use a bench supply, and look if supplying VPP helps.Make sure the device isn't held in reset, or reset accidentally. Check NRSTAs I said I probably wouldn't connect the 3V supplies, the DISCO has it's own regulator, have not evaluated it's specifications, but if you have your own regulators on board, I wouldn't want them fighting with the one on the DISCO. The ST-LINK function, at least on the DISCO, only requires the grounds to be common.

[nawfal3]

Posted on April 22, 2014 at 13:30 I am experiencing about the same thing... I have made a custom pcb for STM32F429ZI and I program it using the ST link provided from the STM32F429I-Disco. I have made many successfull tests programming the chip either from em::blocks or from STM32 ST-LINK Utility (V2.J19.SO)... The problem that I have is that when I connect to the chip via STM32 ST-LINK Utility the application recognize the chip by giving the ID but it is no more able to erase it or program it....Same thing with em::blocks. (I am using SWD)

[Tesla DeLorean]

Posted on April 22, 2014 at 15:59

That's a bit of a difficult description, so did it work, and then stop? What did you change? Can you change the behaviour by resetting the part with BOOT0 High?

[nawfal3]

Posted on April 22, 2014 at 16:18 Actually..I solved it by reputing the jumpers and connecting to the µC on the disco_board ... Then I removed the jumpers and I connected the ST-link to my home made pcb µC and it worked.... Is it normal that the behavior of the ST link is so unstable?? Is there any good programmer (debuger) that can avoid such conexion problems?

[Tesla DeLorean]

Posted on April 22, 2014 at 16:43

The ST-LINK is not a particularly commercial solution, and using the Discovery boards to program others is clearly a half-assed solution, where the primary driver is initial purchase cost. Here in the real world we try to use standard debugger headers, and connect up the interface in a sufficiently complete manner, and jumper the BOOTx pins.

The Segger J-Link and Keil U-Link have significantly more engineering resources behind them, and they are significantly more robust. Still, it's possible to put user code on the chips that will break the debug interface, so having a method to break-out, or use the BOOTx pins is highly recommend.

[nawfal3]

Posted on April 22, 2014 at 17:16 I am really thinking in aquire J link .... But for the moment how can we tackle this problem with code

[nawfal3]

Posted on April 22, 2014 at 17:27

I found this one on mouser.co.uk

http://uk.mouser.com/new/segger/seggerjlink/

  Is it good? (Does it do the job?) What are the limitations as compared with the more expensive ones? Thank you