Early go!bus reflashing app for STM32-based modules
#21
Posted 16 May 2012 - 11:05 PM
#22
Posted 17 May 2012 - 02:20 AM
#23
Posted 17 May 2012 - 02:21 AM
Okay, that's good info. You didn't really _need_ those 192 bytes, did you?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
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
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?
I attached my hacked up version to this reply
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
Posted 17 May 2012 - 12:54 PM
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
Posted 17 May 2012 - 02:35 PM
Good thinking.Maybe there's a bug with GetObject when you try and read more bytes than is available?
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
Posted 17 May 2012 - 02:41 PM
#28
Posted 18 May 2012 - 03:57 PM
#29
Posted 18 May 2012 - 10:27 PM
Attached Files
#30
Posted 19 May 2012 - 07:21 AM
#31
Posted 02 August 2012 - 02:40 AM
#32
Posted 02 August 2012 - 02:48 AM
#33
Posted 02 August 2012 - 03:08 AM
#34
Posted 02 August 2012 - 03:21 AM
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.Is there an update for the go itself after 4.2.0.0 ? I havent been able to see any mention of one.
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
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
Posted 02 August 2012 - 11:03 PM
Windows Phone Development MVP
President Software Logistics, LLC
Tampa, FL
#37
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
Posted 02 August 2012 - 11:44 PM
#39
Posted 02 August 2012 - 11:53 PM
That sounds like the exact issue.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?
Here's the patch:
http://forums.netdui...dpost__p__32007
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.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.
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
Posted 02 August 2012 - 11:55 PM
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.Will the STM32 reflashing app also work for an STM8? If not, how much work would it be to adapt it?
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