Netduino home hardware projects downloads community

Jump to content


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.
Photo

Looking for a few ninja code contributors...


  • Please log in to reply
69 replies to this topic

#41 Steven Behnke

Steven Behnke

    Advanced Member

  • Members
  • PipPipPip
  • 70 posts
  • LocationLas Vegas, NV

Posted 09 March 2013 - 03:51 PM

Alt print screen should print screen just the active window.

#42 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 09 March 2013 - 04:57 PM

Exactly, then copy into mspaint, crop if needed, save as jpeg, upload (use the full editor) and click "attach to post". There are of course easier ways like the "Snag-it" util which is very clever.



#43 ziggurat29

ziggurat29

    Advanced Member

  • Members
  • PipPipPip
  • 244 posts

Posted 09 March 2013 - 05:22 PM

OK OK, here is the much more anticipated than anticipated screen cap.  while it was burning firmware from a couple hours ago.

 

Anyway, I finished the dfu file parsing enhancement.  Now I need to make the firmware burning part aware of the muliple elements.  That actually should be much easier than the dfu parsing since for the most part I just need to loop the erase and burn parts.

Attached File  netdfu-snap-001.png   50.75KB   53 downloads

EDIT:  seems to be working; as a cursory test I can alternatively flash the official v 4.2.2.0 and 4.2.2.1 on a NP2, and I can ping, and see that the version number changes.  I'm going to do a little more significant testing just now.



#44 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 09 March 2013 - 08:46 PM

Real sweet Dave!

 

Btw, did you start off on my version or from the original zip from CodeProject?

 

I assume the Vid/Pid pair is parsed from the DFU file. Don't know if you tried it yet, but by the ST DFU protocol allows you to specify an address for the bootloader to jump to after issuing a "detach" through the HID interface. Doing this after flashing is complete could put tinyCLR in either a "wating for debugger" state or immediately start running the most recently deployed managed code depending of the "Erase deployment" check box.

 

This would be a nice feature since you then wouldn't have to do a USB cycle to start using the board again.



#45 ziggurat29

ziggurat29

    Advanced Member

  • Members
  • PipPipPip
  • 244 posts

Posted 09 March 2013 - 10:03 PM

Real sweet Dave!

 

Btw, did you start off on my version or from the original zip from CodeProject?

 

I assume the Vid/Pid pair is parsed from the DFU file. Don't know if you tried it yet, but by the ST DFU protocol allows you to specify an address for the bootloader to jump to after issuing a "detach" through the HID interface. Doing this after flashing is complete could put tinyCLR in either a "wating for debugger" state or immediately start running the most recently deployed managed code depending of the "Erase deployment" check box.

 

This would be a nice feature since you then wouldn't have to do a USB cycle to start using the board again.

 

I did, and I couldn't have gotten anything done this quickly without it -- by far that is the meat of the program, the author having already figured out all the native code stuff.  I spent many hours last sunday just to get close to enumerating the usb bus, much less doing actual stdfu work, so it's been a huge leg up.

 

Funny you should mention the VID/PID and also the address on detach:

*  VID/PID, yes you can get it from the DFU, but it's not actually useful in the Netduino case,  Why?  whenin DFU mode, the VID/PID you get is of the STMicroelectronics/boot loader, not of the SecretLabs/Netduino.  I don't even know if SecretLabs has a usb VID, and if it supports the HID mode function to do the 'drop to bootloader'.  Regardless, (0x0483, 0xDF11) is for the STMicro/bootloader, (you can google for it).  You get a hint of this which you use the DfuSe Demo, because it warns you that you are in DFU mode and you can't figure out if it's right for your board.

*  address on detach.  Yes you can, and yes I have, however I currently have a problem, what address?  It works when I specify the TinyCLR address (0x08020000 for NP2), but not for the TinyBooter (0x08000000 for all the products).  I think there may be some address that will work universally since the DfuSe demo has the 'leave bootloader' button which works, and it doesn't know anything about netduino in particular, so that's an area of more research.  Maybe some different version of the command means 'just do a hardware reset'.

 

Anyway, I want to try to do one last thing and then I'll post what I have done thus far.  Whoever has vested interest in particulars of the source repository should probably set it up, because posts to the forum will make for a kind of tacky source control....



#46 ziggurat29

ziggurat29

    Advanced Member

  • Members
  • PipPipPip
  • 244 posts

Posted 09 March 2013 - 11:16 PM

OK I have attached what I did so far, for anyone curious or eager to fiddle with stuff.  I have attached it as a zip.  (There, now I've done zip!  haha).

 

*  I used the existing Code Project code Hanzibal found.  I modded it a little, mostly for the DFU parsing to remove some target/element limitations it had.

*  I mad a project consisting of three subprojects

  *  a NetDFULib -- largely comprised of the existing firmware updater code

  *  a NetDFUGui -- a gui application that functions, but I would consider only just passable.  It has a knubskulledly implemented 'device change' feature that is intended to give real-time indication that you have a device attached in DFU mode that can be flashed.  It works, but I reused a function in the firmware updater that is not optimized for that purpose, and so that could use some work.  I also disabled controls for the erasing feature since I want to do that a completely different way, and the 'care' (as in 'care about vid/pid') since I found out that it is not possible to care about them when you're in DFU mode.  Also, I commented-out the 'restart board in CLR after flashing' functionality since I want to find a product-independent way to do that.  It's easy enough to re-enable; I commented out line 221 for FirmwareUpdater, where it is done.  But that address is for the NP2.  (Currently; it could easily change at some future time when SL makes a new firmware layout).

  *  a NetDFUCmd -- a command line application that I have done zero work on.

 

As mentioned I wanted to improve the 'erase' options over what I was going to originally do, now that I understand the code better.  Similarly, now that I parse the DFU and make an internal representation of the firmware image, I also wanted to support flashing directly from bin/hex/s19 as well.

 

Oh yeah, haha, the progress bar will go backwards -- this is simply because the firmware updater code that computes percent does not take into account the multiple flass sections, so it goes from 10-90 percent for each sections.  I didn't get around to adjusting that before I posted.  I find it kind of fun, but you might find it disturbing if you aren't expecting it.

 

-dave

ps I've got to go do other stuff just now, and won't be back 'till probably tomorrow eve.

 

Attached File  NetDFU-20130309a.zip   850.44KB   8 downloads



#47 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 10 March 2013 - 12:34 AM

>>Funny you should mention the VID/PID and also the address on detach: * VID/PID, yes you can get it from the DFU, but it's not actually useful in the Netduino case, Why? whenin DFU mode, the VID/PID you get is of the STMicroelectronics/boot loader, not of the SecretLabs/Netduino. I don't even know if SecretLabs has a usb VID, and if it supports the HID mode function to do the 'drop to bootloader'. Regardless, (0x0483, 0xDF11) is for the STMicro/bootloader, (you can google for it). You get a hint of this which you use the DfuSe Demo, because it warns you that you are in DFU mode and you can't figure out if it's right for your board. --That figures since it's ROM code. So the Vid/Pid are always the ST defaults then, meaning that Secret Labs went by factory defaults after all. Many vendors let you sub license a Pid under their Vid but usually not for commercial stuff or at least not for consumer products which could then collide. >>* address on detach. Yes you can, and yes I have, however I currently have a problem, what address? It works when I specify the TinyCLR address (0x08020000 for NP2), but not for the TinyBooter (0x08000000 for all the products). I think there may be some address that will work universally since the DfuSe demo has the 'leave bootloader' button which works, and it doesn't know anything about netduino in particular, so that's an area of more research. Maybe some different version of the command means 'just do a hardware reset'. --Maybe Chris knows if there is a generic start address? Otherwise a hardware reset would have pretty much the same (or even better) effect if it can be done programatically through HID or otherwise. >>OK I have attached what I did so far, for anyone curious or eager to fiddle with stuff. I have attached it as a zip. (There, now I've done zip! haha). -- :D >>I also disabled controls for the erasing feature since I want to do that a completely different way, and the 'care' (as in 'care about vid/pid') since I found out that it is not possible to care about them when you're in DFU mode. Also, I commented-out the 'restart board in CLR after flashing' functionality since I want to find a product-independent way to do that. It's easy enough to re-enable; I commented out line 221 for FirmwareUpdater, where it is done. But that address is for the NP2. (Currently; it could easily change at some future time when SL makes a new firmware layout). --Sounds like sensible design decisions to me. >>As mentioned I wanted to improve the 'erase' options over what I was going to originally do, now that I understand the code better. Similarly, now that I parse the DFU and make an internal representation of the firmware image, I also wanted to support flashing directly from bin/hex/s19 as well. --Yes, that would be a great feature for those making homebrew firmware using various compilers not primarily producing DFU files or what have you. >>NetDFUCmd -- a command line application that I have done zero work on. --Good, that should leave something for someone else to work on. As for setting up source a source control repository, Chris mentioned a bit bucket earlier in this thread. Great work Dave, if Kudos where real money one should think you'd be a rich man now :) Sorry for the weird formatting above, the editor and I don't get along very well.

#48 ziggurat29

ziggurat29

    Advanced Member

  • Members
  • PipPipPip
  • 244 posts

Posted 12 March 2013 - 03:43 AM

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....

 

please please do!  personally, I am just trying to get the low-level stuff stdfu functions working, particularly for a command line tool, but I think the rest of the world wants a juicsky gui with riche features.

 

...Great work Dave, if Kudos where real money one should think you'd be a rich man now :)....

 

haha thanks!  and if Kudzu were real money, it would grow on trees!

 

Sorry for the weird formatting above, the editor and I don't get along very well.

 

Oh sweet jesus you are not alone it takes my an hour to do what should be 10 min work of editing.  wtf Id rather wiki syntax at this point....



#49 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 12 March 2013 - 06:47 AM

No, if Kudzo were real money we would all be suffering from the effects of a disasterous inflation :-)

#50 Nevyn

Nevyn

    Advanced Member

  • Members
  • PipPipPip
  • 1072 posts
  • LocationNorth Yorkshire, UK

Posted 12 March 2013 - 07:02 AM

>Sorry for the weird formatting above, the editor and I don't get along very well.

So it's not just me !

 

I find the new editor in the updated software infuriating.

 

Regards,

Mark


To be or not to be = 0xFF

 

Blogging about Netduino, .NET, STM8S and STM32 and generally waffling on about life

Follow @nevynuk on Twitter


#51 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 12 March 2013 - 07:38 AM

@Neyn: Yeah, to include multiple partial quotes from one post (like in ziggurat29's last post) is virtually impossible. If you make one mistake, the formatting is lost and you can't get it back with undo (Ctrl-Z) so you'll have to start all over.

 

@ziggurat29: Btw, do you smoke and do you prefer cigar or ziggurat?

:lol:



#52 ziggurat29

ziggurat29

    Advanced Member

  • Members
  • PipPipPip
  • 244 posts

Posted 12 March 2013 - 03:01 PM

...Yeah, to include multiple partial quotes from one post (like in ziggurat29's last post) is virtually impossible. If you make one mistake, the formatting is lost and you can't get it back with undo (Ctrl-Z) so you'll have to start all over.

...

yeah I worked my butt off on that one.  on this one too!  I usually start out by bracketing the quote in dummy text like 'lalala' before and after, and cut and paste around that to a new area where I edit, so I have a copy to come back to.  Dont hit 'Del' on the first character in the message!  and be sure to immediately add some text before and after the quote block, or later you my find it impossible to add text after the quote!

 

Whoops, now I ruined it (sigh):

 

@ziggurat29: Btw, do you smoke and do you prefer cigar or ziggurat?

:lol:

 

Why ziggurat, of course!  Actually I quit smoking last summer, now I just code, which can be similarly habit forming, but is ostensibly more healthful...

 

OK, we've gone off the rails on this topic!



#53 Lunddahl

Lunddahl

    Advanced Member

  • Members
  • PipPipPip
  • 152 posts
  • LocationEurope, Denmark

Posted 12 March 2013 - 09:12 PM

From a novice users point of view, i think i would be nice if this application could do something like this:

 

1 .Read the MAC address from the board.

2. Flash firmware (overwriting the MAC address)

3. Rewrite the MAC address.

 

Especially because the boards comes preset with a MAC address that is also placed on a sticker on the bottom.

 

In a more advanced version "MAC address" could be substituted with "Network configuration".

 

- Ulrik Lunddahl



#54 ziggurat29

ziggurat29

    Advanced Member

  • Members
  • PipPipPip
  • 244 posts

Posted 13 March 2013 - 01:14 AM

From a novice users point of view, i think i would be nice if this application could do something like this:

 

1 .Read the MAC address from the board.

2. Flash firmware (overwriting the MAC address)

3. Rewrite the MAC address.

 

Especially because the boards comes preset with a MAC address that is also placed on a sticker on the bottom.

 

In a more advanced version "MAC address" could be substituted with "Network configuration".

 

- Ulrik Lunddahl

 

Its a great suggestion, and straigtforward to do, simply by not writing the config sector when flashing.  Then you don't even have to read, flash, restore, you simply don't overwrite it to begin with (along with the other network config, like dhcp vs static).

 

Coincidentally today I noticed SL is now shipping the boards with the MAC preloaded.



#55 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 21 March 2013 - 12:36 PM

I take it, after Dave's great achievements, no further work has been done. Assuming the CLI is still to be created, someone should probably get started on that and I think we need to gather some requirements and features. I suggest we wait creating a code repository until the CLI exists in a first simple version before checking in every thing. Also, I understand there are some improvements needed to be made on the Windows Forms app, testing and so on. What do you guys think, Chris?

#56 tim c

tim c

    Advanced Member

  • Members
  • PipPipPip
  • 31 posts

Posted 21 March 2013 - 02:06 PM

Is the latest code available? I have some time to work on this and a CLI.



#57 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 21 March 2013 - 03:53 PM

Cool, I think that would be great! I'm pretty sure the latest version is in the last zip file Dave uploaded but perhaps i'd better let him answer...

#58 ziggurat29

ziggurat29

    Advanced Member

  • Members
  • PipPipPip
  • 244 posts

Posted 21 March 2013 - 05:43 PM

yes, well mostly; there was some more work I was doing regarding the memory map (for more surgical erasing), and I was breaking out the dfu parser as a separate class (rather than nested in the firmware updater), but that is not completed work, so if you want to start to get familiar with it , it's use the last one I posted since it's stable.

 

-dave

 

ps I hardly recognized you hazibal with your new haircut



#59 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 22 March 2013 - 12:45 PM

ps I hardly recognized you hazibal with your new haircut

Well you know, spring is imminent and so the arctic fox changes his fur ;-)



#60 Patrick

Patrick

    Advanced Member

  • Members
  • PipPipPip
  • 54 posts
  • LocationTampa

Posted 22 March 2013 - 02:10 PM

I'm a little late to the party but I have access to a Beagle 480 USB sniffer and all flavors of Netduino.  If any debugging assistance is required, I'd be happy to help out.






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.