The Netduino forums have been replaced by new forums at community.wildernesslabs.co.
This site has been preserved for archival purposes only
and the ability to make new accounts or posts has been turned off.
Couldn't find my Discovery board so I tried it flashing TinyBooter onto a cerb40 board (pretty much the same uC) and it worked perfectly. For this I had to do three things in preparation:
1. Connected a wire between 3V3 and the LODR pin before connecting to USB to force DFU mode
2. Added "C:ProgramSTMicroelectronicsSoftwareDfuSeBIN" to the PATH environment variable (for some reason it didn't work just dropping the STDFU.dll into the same folder as the test application executable).
3. Changed the Vid/Pids pair on lines 28 and 29 in "FirmwareUpdate.cs" to that of the cerb40.
Afterwards I could use MFDEPLOY.EXE to ping the board in TinyBoother mode and I'm a little of baffled that it went so smoothly. Didn't quite expect that
Also, I tried the latest Netduino 2 firmware DFU file but the application aborted since it didn't like there being two elements inside the DFU file. I guess this is because the Netduino 2 DFU files contain both the TinyBooter and tinyCLR while as GHI have these in two separate files.
This probably means the application needs to be modified in order to support multiple elements. It also needs to know at which address to download tinyCLR (assuming that it's it occupying the 2nd element).
So without further modification, this test application won't work for flahshing Netduino 2s at this point. Making these modifications is probably no biggy. It should only be a matter of having the program extracting each of the two portions from the DFU file and then flash them separately, using a different address for the tinyCLR portion. I'm sure the API can be used to extract different elements from DFU files, it's just not supported by the test application.
I'm at work right now and don't have the STDFU.dll here right now, but most likely it depends on the other DLLs in that directory. If you run: http://www.dependencywalker.com/ Dependency Walker against it it should tell you which dependencies are missing if it is in the application's bin directory.
Hmm, nice find with the code project article. Timely since it was published just a few weeks ago, haha.
I have tested it with a Netduino Plus 2 and can confirm that it works. It definitely needs mods, as Hanzibal points out, to be something you want to tell our mom about, but it does appear do the STDFU bits correctly. To test, I did this:
* took 4.2.2.0 and 4.2.2.1
* extracted the tinyclrs and made new dfu that just had the one section being that extracted tinyclr
* burned 4.2.2.0; then use mfdeploy -> devcap and see, yes, 4.2.2.0 is on it
* same thing with 4.2.2.1; then verified that 4.2.2.1 is on it
So its a pretty good sign that the DFU interface is probably working.
Some other notes:
* I did not try the 'Mass erase' function, since I needed the tinybooter and config sections intact for my test. I can try it later and verify with jtag, but since this is forwarding into STDFU, it probably works.
* I did not have to modify the compiled-in VID and PID, so those are apparently not being checked anyway.
The CPOL license is very friendly, so it may just be a UI effort at this point. So stick a tail on it and call it a weasel, and cheers to Mark McLean, the unwitting code ninja, hahaha.
-dave
ps the dlls you need are stdfu.dll and sttubedevice30.dll. Tube device? Didn't those go out of mode in the 60s?
I'm at work right now and don't have the STDFU.dll here right now, but most likely it depends on the other DLLs in that directory. If you run: http://www.dependencywalker.com/ Dependency Walker against it it should tell you which dependencies are missing if it is in the application's bin directory.
Yes, that must be it, how silly of me. If you like, you can do it when you get back from work.
I have tested it with a Netduino Plus 2 and can confirm that it works.
Well, isn't that nice!
I did not have to modify the compiled-in VID and PID, so those are apparently not being checked anyway
Could also be they happen to be the same because Chris went by the ST defaults ;-)
Dave said above: "[color=rgb(40,40,40);font-family:helvetica, arial, sans-serif;]ps the dlls you need are stdfu.dll and sttubedevice30.dll. Tube device? Didn't those go out of mode in the 60s?"[/color]
... (ragarding vid and pid)...
Could also be they happen to be the same because Chris went by the ST defaults ;-)
could, though the NP2 device reports 483,DF11 and I think the compiled in default is 1234,5678. But no matter, it did work; just a note for anyone implementing a modded gui.
I was kidding of course but to be honest it didn't strike me that 1234, 4567 was foo (embarrassed). The current version obviously doesn't check, instead it requires there be only one device in DFU mode attached to the computer (or else it won't run) and then just assumes that's the one.
I think the Netduino version should do the check. Also, I read somewhere that Vid/Pid can be found inside the DFU file. If this is the case with Netduino DFU files, then the application should verify matching numbers before proceeding.
Anyway, it seems now we've got quite a good base for developing a Netduino 2 re-flashing API and tool in managed C# and that was the general idea. So good luck to those who will take it from here!
EDIT: I can confirm that the Vid/Pid pair is available in the Netduino 2 DFU file. When calling ParseDFU_File method of the API, I got back 0x0483, 0xDF11 which are that of Netduino 2 as reported by ziggurat29.
@Chris: I was under the impression that we now have embryo of what you originally sought after. From what I understand, this is what need be done from here:
* Improve the API assembly by adding a few features
* Enhance the Windows Forms application, improve the GUI
* Create a command line utility
Is there a team working on this now?
@[color=rgb(40,40,40);font-family:helvetica, arial, sans-serif;]ziggurat29: Are you working on this?[/color]
This is really awesome, guys!
I'm researching all of this now. Lots of great resources.
I will post more later tonight and coordinate.
Thank you all very much,
Chris
Hanzibal said : @ziggurat29: Are you working on this?
[color=rgb(40,40,40);font-family:helvetica, arial, sans-serif;]I'm happy to do it, or at least produce a first iteration that others can modify/enhance to taste. But I won't get to it until the 9th, so if someone has a burning desire to forge ahead before then, I won't shed a tear. But it would be good to know either way just to avoid redundant effort.[/color]
I would love to help out more as well. If nothing else we should get access to the bit bucket repository so that we can see what is being worked on and what is left to do.
I would like to think we're off to a pretty good start already with this and as Dave (ziggurat29) said he'll be on it from saturday, I think we should sit tight until we hear from him to avoid any redundancy work. It would not surprise me a bit if Dave comes up with a reposity of some sort.
As you said Tim, we're looking at a dll and two applications of it - a desktop app and a command line util. We practically got the dll since it already contains (one way or the other) all the DFU functionality offered by the protocol as defined by the ST app note. I take it, Dave has set out to refine the dll while the other two would depend on that work.
What do you guys think, in the mean time, should we discuss requirements and features of the user interfaces and if so, which one should we start with, the CLI or the GUI?
OK, yesterday I fried my NP2, sadly (I think it was my evil GSM shield which has caused me so much grief as of late), but on the upside that definitely cleared some time for me to work on this update app. And since Hanzibal found the previous work on Code Project, that surely reduces the scope of effort.
I made a project which has a common lib, a gui, and a command-line tool. I have successfully burned some firmware with it onto my other board. So far this isn't all that much different than the original article other that looking a little nicer. I have to fix the 'one flash section only' limitation, which first will mean I need to read the details of the dfu spec, and then mod the code.
I would post a screenshot now, but I guess alt-prtscn doesn't work in Win7.
I have /not/ set up a repository since chris stated he was going to do that at perhaps bitbucket, and I didn't want to collide with whatever he was planning. As soon as it's moderately stable (which really I think may be hours), I'll at least post a zip here so y'all can play with it and make it even more sexy (since I don't claim to be much more than 'passable' as a UI developer).
Oh, lest I forget. Yes, that still works. Its the whole screen instead of just the active window, but I can then crop in paint. OK, I have it on my clipboard, now how to post in this message; the message editor wants a URL, and Im not in the mood to create a file and deploy it to a web server just to share a simple image.
Maybe Dave has done zip and now only pretends unknowing of how to make a screen in order not to give him self away
Gasp! Haha, never! I would simply say I can't get around to it.
Anyway, I'm going to go back to parsing the multiple image elements of the DFU, and then I'll just post the whole working thing.
error.PNG 2.41KB
15 downloads
