Hi Kenny, You always can use an USB cable and power the board at 5v by it. Carlos

I will continue testing in deep tomorrow, but after flashing the TinyBooter it seems to work like a charm!! As I tought TinyBooter was only intended to boot the TinyCLR I thought it was not neccesary to upgrade it. Now I know something more Thanks Carlos.

While you're waiting for it to start, what happens if you PING your device from MFDeploy? Does it return "TinyBooter"? Nothing?

Pinging... Error: No response from device

Then TinyBooter after some time. The weak thing is that "netduinoPlus_NetduinoPlus" appears in the combo immediately after I connect it

Hi, I upgraded my N+ to 4.2, but only ER_CONFIG and ER_FLASH files. Is it neccesary to upgrade the TinyBooterDecompressor.bin as well? If so, this is only done with SAM-BA, right? What happens if the TinyBooter is not upgraded but the TinyCLR is? As a (i think unrelated) question, I'm observing the TinyCLR is taking very long to start up some times (up to 30 secs) with and without the Eth cable connected. I'm using fixed IP. What could be wrong? Thanks in advance, Carlos.

There's a new feature (SimpleStorage) in .NET MF 4.2 that we're looking at leveraging for this. .NET MF 4.2 will be in beta soon, and then we can start testing the implementation.

Hi Chris,

.NET MF 4.2 is available now. Does it include this capability? If so, how is it possible to use it? For my vote, with a hundred of bytes would be more than enough, for bigger data external EEPROM or SD would be justified.

Our first integration pieces are ADC and PWM (for the new object models) and misc. bugfixes--but this is the next item on the list after those. In the meantime, you can certainly store data on an SD card. [Also, the in-flash data storage will be for things like settings that don't change very often--not for constantly writing data.]

Hi Chris,

I'm aware of the flash aging problem, I just need to write a static setting (around 10 bytes) that will be seldom modified with the config of the application, and that's why SD or EEPROM is an overkill. I don't mind if it's Simple Storage, EWR, or ADO.NET against and internal instance of SQL Server 2010 Micro Edition, I don't care if the performance is good or not, of if it requires 20K of RAM, as I have a lot of it I don't use.
I know there are many people that have more resource constrained applications and might not want to consume extra RAM or FLASH for this, that's why I think the best way to approach it would be as a module using .NET MF APIs so people can choose to include it in the project, or not and use external storage.

Whatever will be OK. Is there any way to access the FLASH memory rawly? If I can take ownership of a FLASH block and rewrite it by myself it will work. I can even use two and implement a corruption-protecting algorithm that writes alternatively on both so integrity can be checked at startup, and old version of the config will always exist.

Carlos.

Its SimpleStorage included already?