Looking for a few ninja code contributors...
#1
Posted 02 March 2013 - 10:11 AM
#2
Posted 02 March 2013 - 10:24 AM
For Netduino gen2, we need to create a C# library which uses the DfuSe Win32 DLL to erase and flash STM32 micros.
How about C++/CLI library (which uses STDFU lib and exposes managed interface)?
#3
Posted 02 March 2013 - 11:10 AM
Thank you for expressing interest
If possible, we want to use P/Invoke from a C# library. There are a few people who have had some success getting this to work that I ran across when googling...
C++/CLI is the backup plan. But we'd like to keep away from unmanaged code (aside from the P/Invokes).
Here is a link to the high-level document; the source for DfuSe is in the DfuSe zip itself (I can also provide a copy if it's not in the newest ZIP).
http://www.st.com/st.../CD00264379.pdf
Chris
#4
Posted 02 March 2013 - 03:54 PM
Are you saying basically a replacement for using the 3 defuse demo tools? If so, this is on my to-do list already, so maybe I can devote some time to it tomorrow, unless someone beats me to it.
In my case, I needed/wanted a command line tool, but I imagine in your case you are wanting a gui.
#5
Posted 02 March 2013 - 10:53 PM
Yes, a replacement for STDFU Tester and DfuSe Demonstrator in particular. The DFU .dll could then be used for command-line tools, custom flashing of devices on the assembly line, etc. We have a bitbucket repository where we can collaborate on this as well... Thanks for your enthusiasm! ChrisAre you saying basically a replacement for using the 3 defuse demo tools? If so, this is on my to-do list already, so maybe I can devote some time to it tomorrow, unless someone beats me to it. In my case, I needed/wanted a command line tool, but I imagine in your case you are wanting a gui.
#6
Posted 03 March 2013 - 09:05 AM
I'm not a developer in nature, but i can contribute by helping with Useability/testing.
Feel free to reach out if you need me.
#7
Posted 03 March 2013 - 05:06 PM
Sounds like an interesting project. I've dug out my netduino lately and have been spending time learning the electrical engineering to do something useful with it, but I'm still a full time developer writing code in C++ and C#.
#8
Posted 03 March 2013 - 05:26 PM
Hmm... I started looking into the STDFU.H provided with the installer and it appears that all of the calls use pascal calling convention. This is not supported by P/Invoke from what I've seen.
#9
Posted 03 March 2013 - 06:10 PM
Hmm... I started looking into the STDFU.H provided with the installer and it appears that all of the calls use pascal calling convention. This is not supported by P/Invoke from what I've seen.
PASCAL is defined as __stdcall, which is the default P/Invoke calling convention.
#10
Posted 03 March 2013 - 06:19 PM
Ah ok, that sounds better then. It shouldn't be too bad to wrap this all up then into a nicer interface.
#11
Posted 03 March 2013 - 10:46 PM
Chris - What would the basic features be for version 1?
#12
Posted 03 March 2013 - 11:31 PM
One thing I noted in the ST app note on their DFU protocol is that a host application can command the device to detach itself, resulting in a re-enumeration. This would mean that the Netduino won't have to be USB cycled after flashing is completed which would be one really nice feature.
I've gathered a few pieces of information that might be helpful to any Ninja(s) brave enough to take on this quest for fame and glory. There might be some redundancy here as to what have already been said earlier in this thread but anyway, there you go.
I take it, STDFUDemo.exe and in turn STDFU.dll relies on WinUSB.dll for communicating to the device once the bootloader has entered the DFU loop (after the press and hold thingy). I can't seem to find any information on exactly what functions and so on is provided by STDFU.dll, but I guess it's pretty much what the app note tells us about the capabilities of the bootloader. Maybe Chris has got some more explicit information on this?
Either way, this article on CodeProject describing a C# DFU API should be very interesting (also contains links to further info):
http://www.codeproje...e-Upgrade-DFU-D
Found this document from MS mentioning talking to a device in DFU mode from Windows using the WinUSB API. The doc is supposedly valid for Windows 7 but doesn't say anything about Win 8:
http://msdn.microsof...e/gg487341.aspx
#13
Posted 04 March 2013 - 01:22 AM
STDFU.dll contains a handful of functions in the STDFU.h file:
[font="'courier new', courier, monospace;"]STDFU_GetDeviceDescriptor[/font]
[font="'courier new', courier, monospace;"]STDFU_GetDFUDescriptor[/font]
[font="'courier new', courier, monospace;"]STDFU_GetStringDescriptor[/font]
[font="'courier new', courier, monospace;"]STDFU_GetNbOfConfigurations[/font]
[font="'courier new', courier, monospace;"]STDFU_GetConfigurationDescriptor[/font]
[font="'courier new', courier, monospace;"]STDFU_GetNbOfInterfaces[/font]
[font="'courier new', courier, monospace;"]STDFU_GetNbOfAlternates[/font]
[font="'courier new', courier, monospace;"]STDFU_GetInterfaceDescriptor[/font]
[font="'courier new', courier, monospace;"]STDFU_Open[/font]
[font="'courier new', courier, monospace;"]STDFU_Close[/font]
[font="'courier new', courier, monospace;"]STDFU_Detach[/font]
[font="'courier new', courier, monospace;"]STDFU_SelectCurrentConfiguration[/font]
[font="'courier new', courier, monospace;"]STDFU_Dnload[/font]
[font="'courier new', courier, monospace;"]STDFU_Upload[/font]
[font="'courier new', courier, monospace;"]STDFU_Getstatus[/font]
[font="'courier new', courier, monospace;"]STDFU_Clrstatus[/font]
[font="'courier new', courier, monospace;"]STDFU_Getstate[/font]
[font="'courier new', courier, monospace;"]STDFU_Abort[/font]
It seems that almost all of the function calls require a PHANDLE which I believe would come from the USB Device Enumeration, but there appears to be no support for enumerating HID devices in the STDFU dll itself.
Also, in case you didn't know the Dfuse installs some of the source code in the following location:
C:Program Files (x86)STMicroelectronicsSoftwareDfuSeSources for amd64
or
C:Program FilesSTMicroelectronicsSoftwareDfuSeSources for normal 32 bit x86.
Edited by Steven Behnke, 04 March 2013 - 01:31 AM.
#14
Posted 04 March 2013 - 08:00 AM
Great, its according to the app note then. USB HID communication is easily dealt with in Windows and there are several managed APIs available. I have worked quite a lot with HID programming - basically you read and write from/to binary input and output reports respectively. Just like DFU, the protocol is vendor specific so you would need a document describing it - either that or a USB sniffer :-)
Btw, where and when does USB HID come in to play?
The CodeProject article that I linked to is supposed includes source code for an STM32 C# DFU API class but it seems to be temporarily unavailable. Hopefully it's there again soon and could very well be it contains all the stuff needed.
#16
Posted 04 March 2013 - 11:13 AM
Thanks, I didn't see that. Took only a quick look but it seems to contain all the STDFU.dll library imports needed for P/Invoke in order to do firmware flashing over DFU from managed C#
The class is tested for the [color=rgb(17,17,17);font-family:'Segoe UI', Arial, sans-serif;]STM32F207 which is covered by the same AN3156 app note describing the [/color]DFU protocol used by Netduino 2's STM32F205. From my viewpoint, there's a[color=rgb(17,17,17);font-family:'Segoe UI', Arial, sans-serif;] [/color]good chance the class would work off-the-shelf. Also, the license (Code Project Open Licence, CPOL) is such that the code may be freely used and/or modified.
Someone ought to try the code out once the zip is available for download (I've posted a comment on the code 3rding a couple of other guys also asking for the download). I'd gladly try the code but unfortunately I don't own a Netduino 2 (or a N2+).
EDIT: I read that DFU files are supposed to contain the USB Vid/Pid of the device for which the contained firmware is intended. This would allow the application to verify that the target is in fact the correct DFU device prior to initiating communication with it. The OS provides the Vid/Pid after USB enumeration is done.
#17
Posted 04 March 2013 - 07:35 PM
http://tinyurl.com/d3d42lf
(the original url didn't go in this forum..)
--
Asbjørn
#18
Posted 04 March 2013 - 07:38 PM
Ok, so instead of waiting for the zip to become available I gathered the source code from browsing and put together a VS project (attached below) containing one STDFU class library and a demo Windows Forms application.
I've only made insignificant changes and it's essentially all just been ripped from the CodeProject article by Mark McLean so I put a banner inside.
Be warned: As said, I don't have a Netduino and therefore I cannot test the application myself. First study the source code, should you then decide to take it for a test spin, it is at your own risk and I can't be blamed if you brick your Netduino.
Very early basic instructions from the top of my head (bound to be some quirks):
1. Download the latest Netuino 2 firmware and unzip
3. Open the project in VS (I used 2010 Express on Windows XP)
4. Attach your Netduino to USB while holding down the pushbutton to force it into DFU mode
5. Run the "STDfuAPITester" Windows Forms test application by right clicking the project and selecting Debug -> Start new instance...
6. Hit the "Load file and program..." button and hope for the best but expect the worst
Good luck!
EDIT: Just realized that the USB Vid/Pid used by Netduino 2 is probably different that the pair used by the software (again, I don't know since I don't own an N2). If so, they must be modified and this is done in FirmwareUpdate.cs on lines 28 and 29.
const UInt16 HID_VID = 0x1234; const UInt16 HID_PID = 0x5678;
Could somebody check what the Vid/Pid pair of the Netduino 2 and 2+ are?
Attached Files
#19
Posted 04 March 2013 - 08:30 PM
Hmm.. Amazon Prime could get me a Netduino 2 on Wednesday. I wonder if I should pull the trigger and try this out.
#20
Posted 04 March 2013 - 09:00 PM
Actually, I think it would be pretty safe to try since I believe the bootloader sits in ROM and thus can't be modified. Since entering DFU mode does not rely on software, you should always be able to get it back into DFU mode even if download was to fail midway or the firmware becomes corrupted.
But then again, I'm only guessing here and I could very well be wrong, so be careful.
Maybe someone with spare boards could try it first?
I just realized I got an STM32F4 Discovery board in my junkbox and might give that one a try just to see what happens. I don't expect it will magically turn into a Netduino - raher it will probably not work at all since I suspect clocks are setup differently because of different crystals. It might be worth a try though, just to see if the download works and if I can get it back into DFU mode again afterwards using the boot0 and boot1 pins.
EDIT: I updated the post containing the software regarding the actual USB Vid/Pid pair of the Netduino since these might be different than expected by the software.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users