Nucleo-F411RE - STLink does not function

[tonofsteel]

Posted on September 19, 2015 at 21:02

After using the Disco boards for awhile I have recently purchased a Nucleo board to try out.

I plug it in to the same tools I was successfully working with the F4 Disco board and... nothing! STM Dfuse demonstrator does not even list it as being connected in the drop down, and when I try to connect using Open OCD it fails. I have downloaded the new STlink drivers off of the Nucleo F411 web page and updated both the ST link driver and the firmware on the board (2 separate downloads) Strangely enough the included flash tool to update the on board STlink connected fine and said it was updated but when I go back to the DFuse or OpenOCD tools there is still nothing there. One other peculiar thing is that the mbed part of it seems to add a new drive in windows explorer when connecting the board. The only suggestion I have found on forums is to update the drivers, which I did, and now I am at a loss. I really am not interested in the mbed platform so how do I get this back to a dev board that will work with the standard tools?

[tonofsteel]

Posted on September 19, 2015 at 21:51

It showed an error but actually did work.....

See below

[tonofsteel]

Posted on September 19, 2015 at 22:01

So I will type this up again since when trying to post all I got was an error and everything was lost.  Everything ST is garbage today, literally.

So I tried to jumper the BOOT0 pin to 3.3V to get it into DFU mode a la documentation.  But alas! still no connection with the DFU demonstration tools. WTF? I don't think I can remember all the last 100 iterations of trying to get connected to this piece of junk but I feel like I tried everything. So abandon that method and went to the STLinkV2 page and downloaded EVERYTHING off of it.  Uninstalled everything and then started from scratch installing the STlink drivers, updating the STlink firmware on the board and then installing the ST Link Utility. I can now connect to the board using the utility and erase/program etc.  So now that there is comm occurring this is a no brainer to get the OpenOCD etc going right? Wrong! No DFU tester with/without BOOT0 jumper, toolchains do not detect that STLinkV2 even exists either. The thing that is most frustrating is that the Disco boards were NEVER this stupid to get working.  What the hell changed with these?  I studied the schematics looking for a mystery ''mbed stupid mode'' but I cant find anything that looks to affect operation. Where do I find the STlink firmware to get rid of all this mbed junk?  I still see that after updating everything from the STLink V2 page that the stupid mbed drive shows up.  I do not want this!! 

[tonofsteel]

Posted on September 19, 2015 at 22:24

Digging around I found:

https://community.particle.io/t/how-to-flash-a-brand-new-freshly-soldered-stm32f103-chip/3906

Which basically says to downgrade the stlink firmware (yes! Get that mbed junk off of here!) Which leads to the old STlink firmware here:

https://drive.google.com/folderview?id=0Bzv7UpKpOQhnbXJVVEg4VUo2M1k

I download and try to run and it says the the STLink V2 is non-existent.  Just like all of my dev toolchains and the DFU utility also says.  So definitely something is going on here.  It looks like the newest drivers for the STlink V2 breaks all the old functionality. I DONT WANT YOUR MBED JUNK!! Get it off!!!!!!! Now I am sorry I didn't order the stand alone STLink programmer and snap this piece of shit mbed stuff off of here and burn it. Tried a different computer and still the same results.  This is getting old fast.....

[Tesla DeLorean]

Posted on September 20, 2015 at 00:51

Ok, DFU mode *ONLY* works where you have direct USB connectivity to the chip, in this case the F411. You *DON'T* have this on the Nucleo boards, because there is ONE USB connector and it is connected to the F103 part providing the ST-LINK / SWD functionality. DFU does not work abstractly through a debugging connection.

The ST-LINK firmware on the Nucleo also provides a USB VCP connection to USART2 PA2/PA3 on the F411. You can ignore the mbed stuff, you can use the ST-LINK to overwrite every thing on the F411, and you don't have to use the USB MSC function. No idea why the OCD stuff doesn't work, that's something you'll have to take up with them, it's not an ST product. If it works properly with all ST-LINK releases it should work here, resolve this with OCD.

[tonofsteel]

Posted on September 20, 2015 at 01:33

Thanks clive1, yes this is a huge oversight on my part.  I was working on a different board that had this and in my panic I tried to use this as a ''test'' erroneously.

I used the ST-LINK utility to connect to and erase the board.  I have an older STM32VLDiscovery board here that I used for testing my toolchain and connections side by side with the F411 Nucleo.  The connect and erase works for both the disco and the Nucleo when using the utility. The OpenOCD based toolchain will work with the old board but will not work with the new, it says it cannot find the device. Recent STLink V2 firmware has breaking changes in it and it should not be classified as a V2 anymore.  Should be a V3 or something IMHO since you cannot downgrade it or use it with tools that relied on an earlier version.  Also at one point there was a screen saying the the VID/PID or USB descriptors are not correct for a STLink V2, this only occurs with the new STLinkV2 firmware. This is extremely dangerous since when I connect to my old disco board the utility prompts me to update my STlink firmware which would be a disaster since it would then ''brick'' this board to my toolchain.  That given no warnings or other hints about the compatibility being completely changed and broken. I have spent all day trying to connect this board by installing/uninstalling/spinning up fresh virtual machine installs and every possible iteration I could think of.  The only thing I cannot change is the STLinkV2 firmware since even though I could find the old versions the tool will say that there is no STLink device connected (although when I connect the old disco board it finds it no problem) This is a bunch of BS as far as I am concerned and although you suggest it is OCD's problem I respectfully disagree, ST should have versioned this a V3 or something, especially when ST's older update tools will not even recognize a STLink connected with newer firmware anymore. I am still at a loss of even what to do next, there is no obvious next step except to throw this ST junk in the garbage and move on to potentially better products.

[Tesla DeLorean]

Posted on September 20, 2015 at 03:31

While there was definitely some teething issues moving from the V1 (VLDisco) and V2, mainly with drivers and DLLs. I'm not encountering any of these connectivity and interchange issues with Keil or the ST-LINK Utilities with DISCO or NUCLEO boards. I've got quite a mix of boards here, and external ST-LINK's, so I've got some reasonable perspective on this.

OCD are a third party, they aren't making the hardware, they need to support the hw/sw of the ST-LINK as it exists in the field, or specify which firmware versions they support. I suspect a lot of there code base is the result of reverse engineering, I can see that it would be helpful for ST to submit patches or enhancements to their work.

[tonofsteel]

Posted on September 20, 2015 at 20:45

Well today is another day and I am now resigned to the fact that this is going to be more complicated than plug and play. 

Thank you for the feedback Clive1, since you do not experience any of these issues and can switch back and forth between them with no problem then there must be a shooting solution here somewhere.  One question though, did you update the ST-Link firmware version on the old disco boards you were trying out?

The version of ST-Link firmware that does NOT work for me is V2J24M11

The version of ST-Link firmware the does work is V1J12S0

So right there is a big difference, one is V1 firmware and another is V2, maybe I never was using V2 at all ever due to the pre-loaded firmware on the disco boards I have here (newer mfg dates might have the latest firmware I am guessing)

Right now I am running the ST-LINK Utility to pull these numbers off.  Just for the sake of trying after connecting I hit the ST-Link Upgrade that is a part of this Utility.  When I push the Device Connect button I get:

''No ST-Link found after GoToUsbLoader command.  Wait for the end of USB enumeration then try again''

Then if I try to do anything with the board I get ''No ST-Link device detected.  Please connect it and then retry''

If I unplug/plug then the Utility connects fine to it again.  I am unable to connect to it using the ST-Link Upgrade utility though, it will throw the GoToUsb error whenever I try to connect and then put it into a strange state.

Ahhh and now another clue.  After all of this occurred I went to check out the Device Manager before unplugging.  So it currently is in the state where the Upgrade utility cannot connect (after 1 attempt and then error thrown).  There is a ''STMicroelectronics STLink dongle (WinUSB)'' under the Universal Serial Bus devices  With this shown my OpenOCD toolchain will find and connect to the board. 

However when testing it out it says ''The selected transport doesn't support this target embedded:startup.tcl:21: Error: invalid command name ''stm32f4x.cpu in procedure script''

So there must be some latent driver issues here.  I can reproduce the different connection states now:

- Plug in Nucleo board - ST-Link Utility can connect, OpenOCD toolchain can not connect - Run ST-Link Upgrade utility - throws error when trying to connect- now ST-Link Utility can not connect but OpenOCD toolchain can connect

And another further discovery! 

 When I uninstall the ''STMicroelectronics STLink dongle (WinUSB)'' from the control panel and select ''Delete the driver software for this device'' I now get ''STMicroelectronics STLink dongle'' under USB devices when I connect the Nucleo.  And now the ST-Link Upgrade utility WILL connect with no errors.  I just tried to upgrade the firmware and it is successful.

So there IS a driver conflict here.  I don't know if it is the only issue though since OpenOCD was throwing errors previously.

So in summary:

- My OpenOCD toolchain requires ''STMicroelectronics STLink dongle (WinUSB)'' Usb device driver - ST-Link Upgrade requires ''STMicroelectronics STLink dongle'' - ST-Link Utility can use either of the above

I went through the connect and delete driver / remove from system 2 times before it would connect and say no driver was found.  So I am guessing that means there were several drivers in the windows driver store.

So now the device shows up with a red X in device manager under ''Other Devices'' and is listed as ''ST-Link Debug''

The only driver I can find is this one:

http://www.st.com/web/en/catalog/tools/PF260219

STSW-LINK009

Which is the ''STMicroelectronics STLink dongle'' driver that does not work with my OpenOCD toolchain.

What I subjectively did not want to believe from Clive1's advice looks to hold true: OpenOCD NEEDS to add support for the STSW-LINK009 driver?  (Update from completion of post: this driver appears to be supported but my OpenOCD toolchain's knee-jerk reaction is to brute force its known WinUSB driver install prompt, but offers it as an option, decline and it seems to still work to connect without installing conflicting drivers that cause headaches)

Bah, I was happily developing the disco boards until this Nucleo blew everything up.  And after all of that still I cannot Google anything related on how to fix this or if there is even anyone else that is experiencing this.....

Final update:

- After removing and deleting from the driver store every driver that comes up I manually installed the STSW-LINK009 ''STMicroelectronics STLink dongle'' driver.  Then when I go into my toolchain to test out the connection I get the message: ''STMicroelectronics STLink dongle'' does not appear to have ''WinUSB'' driver installed. OpenOCD may have problems finding your device. Try installing it now?''

This must be where everything falls apart because by default I would just click yes and then this is the point where the conflicting driver gets installed.  I would then have 2 drivers for the same device and depending on USB enumeration one or the other would get activated for the device (which would lead to either STLink or OpenOCD being able to connect)

If I click no I get the identical OpenOCD error as listed above.  So it actually appears to be connecting at first glance here without the explicit WinUSB driver.

The adventure continues................