33 replies to this topic

[Klop]

Hi all, I'm new here and new to the micro framework and netduino plus. I think it's very cool you can write C# code for the microprocessor and debug you code using VS 2010. I have a program were schedules are managed. These schedules needs to be loaded to the flash at a specific memory location. The running netduino main program will then look at this specific memory location for the schedules. So it should be possible to write schedules/data to the internal flash without using the development tool and without writing the "main" running program to the microprocessor. The two parts are decoupled from each other. I believe that should be possible? Does anyone of you know how to manual read/write to the internal flash? How do you access the netduino usb driver - which .dll file is it using and which methods are accessible? Is there any source code for the micro framework so the implementation can be looked at? Hope you can help me. Thank you.

[Mario Vernari]

I asked the same question a time ago, and it is not possible (at least along an human way). The easiest way to do what you desire is using the SD: you may use it as a normal drive. About the resources, there are many useful links on the "Downloads" tab, above in this site. Cheers

[Chris Walker]

Hi klop, The source code is available on the downloads tab. You can read/write flash using the MFDeployEngine (which is used internally by MFDeploy). When the v4.2 SDK is released, we'll include the ability to read/write a bit of flash data from your Netduino app. Chris

[Klop]

Hi Chris, Is it possible to read from flash something like: Utility.ReadCodeFlash(IntPtr p, Int offset, Int length); ? Or By using a flash pointer something like: flash const byte* codemem = (byte*) 60000; // reading from flash location 60000 ? Or do you have any other suggestions? Thanks.

[Klop]

Hi again, Chris do you know if this would be possible or how it would be possible: byte* b = (byte*) 0x0010000; // start of flash address location in the ARM7 Like you could do in a C# windows app to access the memory directly (unsafe mode of course) We would of course put our custom data in the upper end of flash were no code is located. Which would be uploaded by our custom boot loader. Or is the only way to do this with the interop feature and link some native code with the micro framework firmware? Thanks.

[Mario Vernari]

I am *far* to be an expert of native level programming (i.e. C/C++), but I have some doubt about the ability to store custom data using this way. I played a bit with unsafe stuffs and C#, but it seems to me that is *very* limited compared to C++. Primarily because the code must take in account the GC and there is not any marshaling utility in the MF. The GC force you to consider almost anything as "fixed" and that is closing a lot the ability to to whatever you want. I didn't found such as a "freedom" as the C++ gives you. About the marshaling, I was not able to pack/unpack an array of floats to/from an array of byte. Moreover, if you have a custom struct, to serialize it as a byte array, you should define the layout kind. That is not possible under MF, because the is not the LayoutKindAttribute. Again, maybe it's me, but I found very hard (almost impossible) to perform some basic interop tasks. Cheers

[Klop]

You can read/write flash using the MFDeployEngine (which is used internally by MFDeploy).

When the v4.2 SDK is released, we'll include the ability to read/write a bit of flash data from your Netduino app.

Chris

Has anyone here used the MFDeployEngine.dll for detecting the Netduino USB, connect to it and read/write custom data to the flash/memory?

I've created a little test Windows form app which easily detects the Netduino, connects to it and pings it via the MFDeploy class and tbe MFDevice class from the MFDeployEngine.dll.

But when going a step deeper by using the _DBG.Engine and trying to connect to it I'm getting exceptions. As I can see it I need an instance of the Engine to be able to read/write directly to the flash/memory with the methods ReadMemory(...) and WriteMemory(...).

Does anyone know if I'm on the right track here? Hope you can help me out.

Thanks.

[CW2]

Does anyone know if I'm on the right track here? Hope you can help me out.

I think so. You might want to check out MFDeploy source code, it is included in the Porting Kit or you can browse it online.

[Klop]

I think so. You might want to check out MFDeploy source code, it is included in the Porting Kit or you can browse it online.

I'm looking at the MFDeploy source code and have located a Deploy method in the MFDevice class in which a direct memory write is called on the _DBG.Engine: the WriteMemory(...) method.

I've succeded creating an instance of the _DBG.Engine class - but everytime I try to call a method on it I get the following Exception:
if(!m_state.IsRunning) throw new ArgumentException( "Controller not started, cannot create message" );
thrown in the debugger Controller class ln 503.

I'm having a hard time figuring out how to start the controller or if it's something else. Does anyone know what the problem is?

Thanks.

[CW2]

The following code demonstrates simple way to read and write flash memory via Debugger.Engine. Please note it is just for experimental purposes, error checking has been omitted for sake of clarity and the device should be probably rebooted at the end. Use at your own risk

Strange thing: It seems the data written to the storage block persists until the CLR engine is executed, then it is erased - I have not investigated it further, it may be caused by initialization of the block storage device driver. I did not really want to write into deployment or configuration area.

namespace MyMFDeploy
{
  using System;
  using System.Linq;
  using System.Reflection;
  using Microsoft.NetMicroFramework.Tools.MFDeployTool.Engine;
  using Microsoft.SPOT.Debugger;

  static class Program
  {
    static void Main()
    {
      using(var deploy = new MFDeploy())
      {
        // Connect to the first USB port
        var usbPort = deploy.EnumPorts(TransportType.USB).FirstOrDefault();
        if(usbPort != null)
        {
          using(var device = deploy.Connect(usbPort))
          {
            if(device.ConnectToTinyBooter())
            {
              // Get the DbgEngine (via reflection, because the property is iternal)
              var prop = typeof(MFDevice).GetProperty("DbgEngine", BindingFlags.NonPublic | BindingFlags.Instance);
              System.Diagnostics.Debug.Assert(prop != null);
              var dbgEngine = (Engine)prop.GetValue(device, null); // Direct cast used for type validation
              System.Diagnostics.Debug.Assert(dbgEngine != null);
              System.Diagnostics.Debug.Assert(dbgEngine.IsConnected);

              const int StorageBlockA = 0x17A000; // Size 0x2000
            //const int StorageBlockB = 0x17C000; // Size 0x2000

              // Data to be written in the middle of storage block 'A'
              var data = new byte[] { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };
              var dataAddress = (uint)(StorageBlockA + 0x1000);

              // Inspect the memory content
              byte[] buffer;
              if(dbgEngine.ReadMemory(dataAddress, (uint)data.Length, out buffer))
              {
                System.Diagnostics.Debug.WriteLine(BitConverter.ToString(buffer));
              }

              // Erase is required before Write (?)
              if(dbgEngine.EraseMemory(dataAddress, (uint)data.Length))
              {
                if(dbgEngine.WriteMemory(dataAddress, data))
                {
                  // Check signature - commit (?)
                  if(dbgEngine.CheckSignature(new byte[128], 0))  // Empty signature
                  {
                    // Write succeeded, verify
                    if(dbgEngine.ReadMemory(dataAddress, (uint)data.Length, out buffer))
                    {
                      System.Diagnostics.Debug.WriteLine(BitConverter.ToString(buffer));
                    }
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}

[Klop]

The following code demonstrates simple way to read and write flash memory via Debugger.Engine. Please note it is just for experimental purposes, error checking has been omitted for sake of clarity and the device should be probably rebooted at the end. Use at your own risk

Hi CW2, Thanks alot - I'll try out your code and see if I can get it to work the way I want. Simply put I just want to write some data (a struct) from an desktop app into the available user flash memory area which the netduino code then can access. That should be possible - it doesn't sound very complex at all.

Thanks.

[Chris Walker]

Hi Klop, You can embed data inside your app if you want as well. .NET MF supports resources. .NET MF 4.2 (beta coming by summer) includes a new "simple storage" mechanism for storing data on-chip. We'll be embracing this in the Netduino 4.2 firmware to enable you to read/write data from your Netduino app as well. Chris

[Klop]

You can embed data inside your app if you want as well. .NET MF supports resources.

That's also very nice but unfortunately I cannot use this feature. I'm going to have a running netduino device which needs to access data in the flash memory (always same start address). The data needs to be written/uploaded to the flash memory from en external windows app by connecting the netduino device via USB.

Do you know which address area that is not used by the MF and the netduino firmware? There must be some empty user flash area to use. Can you maybe help with clarifying this?

[Klop]

Strange thing: It seems the data written to the storage block persists until the CLR engine is executed, then it is erased - I have not investigated it further, it may be caused by initialization of the block storage device driver. I did not really want to write into deployment or configuration area.

I have now played around with your code example and am able to persist the data written to the memory but the netduino firmware seems to get unloaded/erased! I can unplug and plug in the netduino again and again and the written data is still there. But when pinged the netduino only response with 'TinyBooter' and not which I had hoped 'TinyCLR'

Does anyone know why the netduino firmware gets removed simply just by writting some data to the "empty" flash memory?

[CW2]

Does anyone know why the netduino firmware gets removed simply just by writting some data to the "empty" flash memory?

If I remember it correctly, there is a note in the Platform Kit documentation that says something about TinyBooter erasing blocks if the verification fails and that there are security measures to protect against overwriting. The code is obviously missing something important here, perhaps a valid signature or security key.

[Michel Trahan]

.NET MF 4.2 (beta coming by summer) includes a new "simple storage" mechanism for storing data on-chip. We'll be embracing this in the Netduino 4.2 firmware to enable you to read/write data from your Netduino app as well.

Just to see that I understand : lets say you have a normal netduino with XBee but no SD card, you could send info to the netduino that would persist even after power recycling (like encryption key or remote ip address of neighbor sensor or ...) ? That could be interesting

[Chris Walker]

Hi Michel,

Just to see that I understand : lets say you have a normal netduino with XBee but no SD card, you could send info to the netduino that would persist even after power recycling (like encryption key or remote ip address of neighbor sensor or ...) ? That could be interesting

Yes, you'll have 4KB or more of storage space to store data. It only has 10,000 rewrite cycles for flash rewrites...so you won't want to rewrite it frequently...but it'll be awesome for configuration data.

And of course, Netduino Plus has MicroSD support...so you can store data there easily too.

Chris

[Michel Trahan]

Yes, you'll have 4KB or more of storage space to store data. It only has 10,000 rewrite cycles for flash rewrites...so you won't want to rewrite it frequently...but it'll be awesome for configuration data.

Quite ! specially for very small remote sensors using the mini ! Configuration yes, daily values ... not really since 10,000 cycles (about 27 years if one per day)

And of course, Netduino Plus has MicroSD support...so you can store data there easily too.

Was thinking of the mini or normal ones

[Klop]

Do you know where in flash to persist your custom data? And what the different segments (Code, Deployment and Configuration) are used for? Does the Code segment contain my netduino app or does it contain the micro framework or both? The following is the flash sector map printed with the MFDeploy tool. Flash Sector Map Command Sector Start Size Usage ----------------------------------------------- 0 0x00100000 0x0000c000 Bootstrap 1 0x0010c000 0x0005a000 Code 2 0x00166000 0x00018000 Deployment 3 0x0017e000 0x00002000 Configuration Flash Sector Map Complete I have been trying to use the Storage Block A at address 0x17A000 and is able to persist custom data here - but it gets erased when I build/debug and deploy my netduino app from Visual Studio. Is it not possible to keep the custom data when debugging? Is there somewhere else in the flash area to persist custom data? Thanks.

[CW2]

And what the different segments (Code, Deployment and Configuration) are used for?

• Bootstrap - bootloader (TinyBooterDecompressor.bin),
• Code - CLR and native code (ER_FLASH),
• Deployment - application and managed dlls (via MFDeploy or Visual Studio),
• Storage A, B - for Extended Weak Reference,
• Config - configuration data (ER_CONFIG, e.g. network settings)