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.
Early go!bus reflashing app for STM32-based modules
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.
Thanks for the patch! I'll apply it this weekend!
I was actually looking at the variable labs prototype module, and then I recalled I already had the STM8S-discovery board, which I could probably use for now, although it is a little overkill.
Right now Im looking at which free toolchains to use to set up something so I can program the discovery board - do you guys have recommendations for an STM8S toolchain? Ive downloaded a few pieces today, the "ST Visual Develop" IDE (with the unfortunate name of STVD), and it seems to want an additional, external 3rd party compiler toolchain (I thought I -was- installing a compiler/toolchain!), and it suggests "STM8 Cosmic" or "Raisonance", and my efforts to connect the pieces so far hasnt worked out.
What I want to do is basically to: 1, get a toolchain set up and be able debug into the ST discover board (I'll surely need to do that on my own (unless you guys have some helpful pointers?) and 2, maybe/hopefully get a standard-generic-Gobus-module-firmware-source-template-project (too many words there!) from you guys that will run on the STM8S105C6T6, that I can compile with the chosen toolchain, make changes, and run on the discovery board - and then I'll be off and running!
Any suggestions? I havent gone through all the applicaiton notes for the discovery board yet, so there might be answers in there...
BTW, I like the idea of the shieldbase as an expansion-interface module too. I have two of them just waiting for the release code! As soon as it is available, I hope to use both of them, with the two macetech "centipede shields" that I have, to give my Ngo an additional 128 GPIO. This could work in theory, right? I2C over pins 4 and 5?
I guess the question is when to add stuff to the Ngo as a Gobus module, and when to add it as a shield to the shieldbase...
Doh! Thank you. I'm retarded. I went to the main wiki page, and failed to see the "Firmware development" link at the top, focusing only on the main list of links below. That would have saved me a lot of time, lol. But thank you for pointing that out, and for the other devlopment efforts, they are appreciated. And now I have validation that I wasnt barking up some randomly wrong tree with these toolchains.
My raspberry Pi gpio breakout boards/cables arrived today though... I will try and force myself to stay focused...
It seems I bricked my two nwazet display screens when I tried to update their firmware - perhaps those last bytes were meaningful after all.
So I'm trying to retrace my steps, and I see your instructions again, and I get as far as "grab the latest shieldbase flasher app" - and I can no longer find it anywhere.
Where does it live now?
I havent been able to successfully flash the displays
The app itself says it succeeds (which is why I thought I was good to go several days ago), but any attempt to run the touch panel demo now leaves the demo code hanging in the "WaitUntilModuleIsInitialized" loop. The screen powers up (the backlight) but thats's it - it never initializes.
I've also tried your suggestion of padding the bin file with a few hundred extra bytes, but that didnt help.
I see all the 256-byte packets being written, up to 0x14900, and then the next packet (with the last 0x8C bytes of data from 0x14900 to 0x1498C with the rest of the packet filled with 0s) - so the entire .bin file (all 0x1498c bytes) gets written, but I cant get it to do anything other than power the backlight after that.
I'm using the correct socket (5) - and I've updated the GO firmware to 4.2, and have the latest 4.2 framework and SDK installed. The demo app has all references to 4.2 assemblies, and built for 4.2 itself...
I think I might need some help, perhaps mailing these back to be flashed/upgraded (is that an option?)
Hi mtylerjr, Fabien:
Could you please plug your nwazet display module into socket 4 on your Netduino Go and then run the attached reflashing app?
Once flashing is done, the output window will show success and blink the power LED. When that happens, move the module to sockets 5-8 (so that the reflashing doesn't accidentally start over).
This should update your display module to the latest firmware from nwazet.
To create the reflash utility for the nwazet touch display, here's what I did. Follow these instructions to make your own manual flash utility for any .bin file.
Save the nwazet .bin file to a folder on my computer.
Run the attached "LengthenBinFile" project to add 256 0xFF bytes to the end of the file. This is a temporary measure to workaround a bug in the NETMF Resources feature. Be sure to change the file names (input and output) in Program.cs before running this app.
Open the "STM32 Reflash App" solution, and double-click on the resources file.
Delete the current resource(s). Also delete them from the "Resources" folder in Solution Explorer.
Add the (256-byte longer) bin file to the resources file (using Add Resource > Existing File)
In Program.cs, change the file name, resource name, and length to match the resource file.
Having said that, we really need a method of upgrading module firmware that's reliable...
We're working on a reflashing tool that can stream bin/hex files from the desktop, but in the meantime this should reliably reflash STM32-based GoModules.