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

Early go!bus reflashing app for STM32-based modules


  • Please log in to reply
61 replies to this topic

#21 Fabien Royer

Fabien Royer

    Advanced Member

  • Members
  • PipPipPip
  • 406 posts
  • LocationRedmond, WA

Posted 16 May 2012 - 11:05 PM

Chris, The data corruption appears at the very end of the flash section, specifically in the last 192 bytes of it. Have fun at Maker Faire :) Cheers. -Fabien.

#22 KodeDaemon

KodeDaemon

    Advanced Member

  • Members
  • PipPipPip
  • 63 posts

Posted 17 May 2012 - 02:20 AM

It looks like those last bytes are not getting written based on the information you guys have provided. I'll setup a test case here to repro and track down the issue.

#23 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 17 May 2012 - 02:21 AM

Chris,
The data corruption appears at the very end of the flash section, specifically in the last 192 bytes of it.

Have fun at Maker Faire :)

Okay, that's good info. You didn't really _need_ those 192 bytes, did you? ;)

Could you please send me a copy of the flashing app with your binaries embedded in it...and the binary as a separate file (so I can do some testing here)? Or point me to where I can grab them?

Thank you,

Chris

#24 Fabien Royer

Fabien Royer

    Advanced Member

  • Members
  • PipPipPip
  • 406 posts
  • LocationRedmond, WA

Posted 17 May 2012 - 02:58 AM

Okay, that's good info. You didn't really _need_ those 192 bytes, did you? ;)

Could you please send me a copy of the flashing app with your binaries embedded in it...and the binary as a separate file (so I can do some testing here)? Or point me to where I can grab them?

Thank you,

Chris


Hey Chris,
Off by one (block) are we? Posted Image

I attached my hacked up version to this reply Posted Image
Check the \Resources folder for the binary version of the firmware.
You can also find the binaries in the [Nwazet BitBucket repository.

Cheers,
-Fabien.

Attached Files



#25 NXTwoThou

NXTwoThou

    Advanced Member

  • Members
  • PipPipPip
  • 68 posts
  • LocationTulsa, OK

Posted 17 May 2012 - 12:54 PM

Maybe there's a bug with GetObject when you try and read more bytes than is available?

Simple step would be to just do this:

int readsize = 256;
                        if (offset + readsize > totalSize)
                            readsize = totalSize - offset;
                        flashFileBuffer = (byte[])ResourceUtility.GetObject(rm, enumID, offset, readsize);

rather than

flashFileBuffer = (byte[])ResourceUtility.GetObject(rm, enumID, offset, 256);
                        
                        // special case: if we've run past the end of the resource, we can get extra data.  if this is the case, remove the excess.
                        if (offset + flashFileBuffer.Length > totalSize)
                        {
                            byte[] tempBuffer = new byte[totalSize - offset];
                            Array.Copy(flashFileBuffer, 0, tempBuffer, 0, tempBuffer.Length);
                            flashFileBuffer = tempBuffer;
                        }

that final pass in this example would have been 196 bytes, pretty close to that 192. Doubt this is it, but since it only takes a second to try.

#26 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 17 May 2012 - 02:35 PM

Maybe there's a bug with GetObject when you try and read more bytes than is available?

Good thinking.

There is actually a bug with GetObject which results in too much data being returned sometimes, when we specify the exact amount we need. Perhaps this is the same issue.

A potential easy workaround, while we investigate a glitch in NETMF's GetObject implementation, would be to enlarge the BIN file by 256 bytes (the size of one write), filling all the extra space with 0xFF, and then potentially incrementing the FlashFile 'Size' value by 256 bytes to match.

Chris

#27 Fabien Royer

Fabien Royer

    Advanced Member

  • Members
  • PipPipPip
  • 406 posts
  • LocationRedmond, WA

Posted 17 May 2012 - 02:41 PM

How about doing away with the resource manager altogether and simply converting the binaries to byte arrays and have them embedded in the app? Works well for bitmap images... -Fabien.

#28 jad73994

jad73994

    New Member

  • Members
  • Pip
  • 3 posts

Posted 18 May 2012 - 03:57 PM

A byte array would make it easier to deploy this utility when it works (no instructions, just run it). It would look a little silly though. Has anyone tried buffering the end with blank space? I think I'm going to try that in a bit.

#29 jad73994

jad73994

    New Member

  • Members
  • Pip
  • 3 posts

Posted 18 May 2012 - 10:27 PM

Chris' solution worked. Adding 256 bytes and then flashing. Here's the code Fabien. Looks like the last buffer may not be flushed.

Attached Files



#30 Fabien Royer

Fabien Royer

    Advanced Member

  • Members
  • PipPipPip
  • 406 posts
  • LocationRedmond, WA

Posted 19 May 2012 - 07:21 AM

Hi Jad, Thanks for taking time to look at it :) I'll test it tomorrow. Cheers, -Fabien.

#31 mtylerjr

mtylerjr

    Advanced Member

  • Members
  • PipPipPip
  • 106 posts
  • LocationChristchurch, New Zealand

Posted 02 August 2012 - 02:40 AM

So, Im trying to find the "latest" info on reflashing the nwazet lcd panels to the current non-blocking firmware... The thread seems to have tailed off after the STFLasherJad project was posted. In lieu of finding anything else that seemed to be apropos, Ive been trying to get that app to work to flash the including binary image to the panels. First, it references a Gobus.csproj that seems to be missing - although if I remove it, the app builds and depoys and runs - but it exceptions out. Ive been googling, poking around, searching, and for the life of me I cant find any coherent information about how to uprgade the firmware in these things, other than some threads with partial back and forth like this one, with no conclusive resolution, or state of how things are. I know this isnt a released product yet, and everytime I see some new developer post about how frustrated they are, I cringe, but tonight I'm really frustrated myself... Why isnt it easier to find information? Surely the flashing app has been used by someone other than the developers, right? IS my search-fu and google-fu that weak? I just want to upgrade my two nwazet panels so I can get back to developing on the GO Platform. I've wasted almost all of my "Free day" this week, now, trying to do just that. I wish Id been able to use that time actually coding :(

#32 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 02 August 2012 - 02:48 AM

Hi mtylerjr, Try this: 1. Grab the latest .bin file for the [nwazet display 2. Grab the latest Shield Base updater (4.2.0.1 beta) 3. Remove the Shield Base .BIN resources from the project and add the [nwazet touch display .BIN files instead. 4. Change the resource name and .BIN file size in the reflash app 5. Plug your module into the mainboard (socket 5 by default) and run the flashing app. Please note that there is a bug in the NETMF Resource classes which can result in a few final bytes from a BIN file being left out. If you add 256 extra bytes (zeros or whatever data you prefer) to the end of the BIN file, that seems to workaround the NETMF bug. We can help with this process if you're stuck. We just need the .bin file you want to flash; we already have the hardware here. Chris

#33 mtylerjr

mtylerjr

    Advanced Member

  • Members
  • PipPipPip
  • 106 posts
  • LocationChristchurch, New Zealand

Posted 02 August 2012 - 03:08 AM

Thanks Chris. That did the trick. Both were succesfully updated (at least if the final block was incorrect, the app didnt complain) I should have asked for help sooner, lol. SO I have both my shield bases updated, and both lcd screens updated... Is there an update for the go itself after 4.2.0.0 ? I havent been able to see any mention of one. I think I am almost ready to start doing some fun stuff again.

#34 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 02 August 2012 - 03:21 AM

Hi mtylerjr,

Is there an update for the go itself after 4.2.0.0 ? I havent been able to see any mention of one.

Netduino Go 4.2.0 has proven to be very stable so far. There's one bug that we addressed in a patch--if you have troubles deploying and running any apps on your Netduino Go, you'll want to update with it.

That said, we are working on a 4.2.0.1 update for Netduino Go which adds support for the new SD Card modules.

Chris

#35 mtylerjr

mtylerjr

    Advanced Member

  • Members
  • PipPipPip
  • 106 posts
  • LocationChristchurch, New Zealand

Posted 02 August 2012 - 05:13 PM

Hi mtylerjr,


Netduino Go 4.2.0 has proven to be very stable so far. There's one bug that we addressed in a patch--if you have troubles deploying and running any apps on your Netduino Go, you'll want to update with it.

That said, we are working on a 4.2.0.1 update for Netduino Go which adds support for the new SD Card modules.

Chris


I probably shouldnt be so lazy, and I should search the forums myself for info on this patch, but can you give me some info?

I can deploy succesfully "often" but I have to physically disconnect the NGo almost every time I recompile or restart, otherwise I get a "cant find entry point!" error.

Does this sound like the issue the patch might address?

And lastly, is there a generic SPI (GoBus) to serial pass through module in the works (or already done by the community) ? I have lots of little TTL-serial modules, sensors, etc - and a generic GoBus module, with maybe a little breadboard that allowed you to plug in the other modules, and just patch-wire 3-4 pins for +3/5v, Gnd, RX and TX would open up hundreds of existing modules to nearly plug and play on the gobus, and not use up a whole uart, just a socket. I guess it would be a Uart module, lol.

#36 ByteMaster

ByteMaster

    Advanced Member

  • Members
  • PipPipPip
  • 76 posts

Posted 02 August 2012 - 11:03 PM

Will the STM32 reflashing app also work for an STM8? If not, how much work would it be to adapt it?
Kevin D. Wolf
Windows Phone Development MVP
President Software Logistics, LLC
Tampa, FL

#37 Lunddahl

Lunddahl

    Advanced Member

  • Members
  • PipPipPip
  • 152 posts
  • LocationEurope, Denmark

Posted 02 August 2012 - 11:25 PM

And lastly, is there a generic SPI (GoBus) to serial pass through module in the works (or already done by the community) ? I have lots of little TTL-serial modules, sensors, etc - and a generic GoBus module, with maybe a little breadboard that allowed you to plug in the other modules, and just patch-wire 3-4 pins for +3/5v, Gnd, RX and TX would open up hundreds of existing modules to nearly plug and play on the gobus, and not use up a whole uart, just a socket. I guess it would be a Uart module, lol.


Sounds like the Shield Base, that has 3 Seriel Ports, and takes up only one socket. The Shield Base is in beta right now, and SPI and UART (Serial) is not enabled, I2C is in the works, Digital and Analog pins works, PWM works via an unofficial beta firmware posted on the forum.

When the Shield Base get's out of beta, you will hopefully be able to connect more than one to the Go. As i understand the Shield Base beta code really uses 4 sockets, even though it's only plugged into one. This should no longer be the case after the beta, and in theory you should be able to connect 8 Shield Bases giving you a total of 24 serial ports.

However i think there is a market for a mini shield base based on the STM8 series, exploiting whatever I/O pins that Micro has as 0.1 headers.

Combined with a standard open firmware people could make changes to that firmware if the needed real time / polling / looping or bit-banging like code, or simply use the standard firmware and write a "driver" running on the Go, together with instructions on how to connect this or that piece of electronics to the mini shield base.

I for sure know that without a possibility to skip either learning to develop for a STM8 or learning to make circuit boards there will be no modules from me, but with a "development platform" like the the above i might dig into hacking some STM8 code to get my favorite sensor to work, then release the stuff as open/free-whatever and get some of the module makers interested in manufacturing and selling this new module.

I somehow think Chris has the same idea's, but i think the development of the current shield base, that is based on the STM32, is the foundation for doing the same thing in smaller scale on the STM8.

Chris ?

- Ulrik Lunddahl

#38 Lunddahl

Lunddahl

    Advanced Member

  • Members
  • PipPipPip
  • 152 posts
  • LocationEurope, Denmark

Posted 02 August 2012 - 11:44 PM

My dreams is to make a solar heater controller module out of the Shield Base + some hardware + perhaps some hacking in the Shield Base firmware (the native C++ code running on the SB). Then release this as one piece of hardware, ready to plug into a Go, with a sample .net solar controlling application, other people can then extend that application to do whatever they want, like being controlled from a smartphone, or logging heat production to the internet, the list is almost endless. What i'm waiting for is the shield base to get out of beta, and the code running on it to be released, when that happens i will figure how to do it. I hope to be able to use DS18S20 one wire sensors, but i will have to bit-bang to them in the Shield Base code, and then i need some PWM outputs for the pumps, and some PWM inputs (counters) for the flow meters. a few relays is also needed, but that should be simple. - Ulrik Lunddahl

#39 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 02 August 2012 - 11:53 PM

Hi mtylerjr,

I probably shouldnt be so lazy, and I should search the forums myself for info on this patch, but can you give me some info?

I can deploy succesfully "often" but I have to physically disconnect the NGo almost every time I recompile or restart, otherwise I get a "cant find entry point!" error.

Does this sound like the issue the patch might address?

That sounds like the exact issue.

Here's the patch:
http://forums.netdui...dpost__p__32007

And lastly, is there a generic SPI (GoBus) to serial pass through module in the works (or already done by the community) ? I have lots of little TTL-serial modules, sensors, etc - and a generic GoBus module, with maybe a little breadboard that allowed you to plug in the other modules, and just patch-wire 3-4 pins for +3/5v, Gnd, RX and TX would open up hundreds of existing modules to nearly plug and play on the gobus, and not use up a whole uart, just a socket. I guess it would be a Uart module, lol.

We're working on adding this functionality to the Shield Base. We're also working on firmware for an STM8S which will let you use the serial pins of the STM8S directly from your mainboard using the standard NETMF SerialPort class (sort of a SPI->UART passthrough). If there's a need for a TTL Serial module (3V3 or 5V), someone in the community could certainly build one. :)

I anticipate that the Variable Labs prototype module will be able to act as a TTL Serial module as well in the future.

Chris

#40 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 02 August 2012 - 11:55 PM

Hi ByteMaster,

Will the STM32 reflashing app also work for an STM8? If not, how much work would it be to adapt it?

The STM32 uses a UART-based reflashing protocol and the STM8 uses a SWIM-based (or bit-banged/emulated) reflashing protocol. So they're quite different.

We're working out the details or an STM8S reflashing app. If you'd like to be involved in that effort, please PM me...

CW2 has run some preliminary tests as well, and is one of our resident STM8 experts when it comes to reflashing.

Chris




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.