26 replies to this topic

[Miha]

Hi!

I'm trying to build a custom firmware which includes native drivers for LCD per this post.

Some notes to begin with, as it is not very clear for a begginer like me:

1. You don't build the firmware with Visual Studio, but rather with command line tools. (msbuild)
2. Download and install Porting kit (link titled .NET Micro Framework v4.1 source in the Downloads section).
3. Download Netduino firmware source, unzip and copy over to porting kit (my location C:\MicroFrameworkPK_v4_1), instructions in the Netduino source.
4. Set your environment: \MicroFrameworkPK_v4_1\setenv_vs10.cmd
5. Go to firmware directory and run msbuild (cd C:\MicroFrameworkPK_v4_1\Solutions\NetduinoPlus and then msbuild).
6. 8 minutes later, I had it compiled with only a couple of warnings.

Then I went about integrating drivers mentioned on the top. I copied over the files necessary and ran the SolutionWizard in order to add the LCD drivers to NetduinoPlus solution.

The solution wizard loaded my netduino project, but when I clicked next, it said "Invalid data has been entered".

The solution wizard project settings are visible on the picture:


What puzzles me here is that flash memory base is higher than flash memory size. But then again, I am no expert in this field so that may as well be correct. When I click next, I get an alert "Invalid data has been entered".

The workaround I've accidentally found is: go back, click on CORTEXM3_SAMPLE project, click next, then go back to NetduinoPlus solution and it will take you to the next screens, where you can choose to add the LCD library in question without error "Invalid data has been entered".

And now, running msbuild produces several errors, the first is:

C:\MicroFrameworkPK_v4_1\DeviceCode\PAL\rtip\lib\dotNetMF_sockets.proj(70,5): error MSB3021: 
Unable to copy file "\\sockets_hal_stubs." to "\\sockets_hal.". The UNC path should be of the 
form \\server\share.

This leads me to think that something is not set up right (paths, variables), but I don't really know where to look. I even copied the original ND solution over without running the Solution wizard again and it does not compile (anymore, that is).

So, apparently, Solution Wizard (not much of a wizard, a? ) broke my microframwork project files. I've not found anything similar on the net, and hopefully, some of you encountered something similar?

I am building this on Windows 7 machine, FWIW.

Thanks,
Miha.

[Corey Kosak]

Regarding the little do-si-do with the Solution Wizard, I encountered exactly the same problem and the same workaround

Regarding building with Visual Studio, I do not think that will work. Visual Studio does not have an Atmel cross-compiler. You'll need to build with gcc (free) or RVDS (pay).

There are several gotchas involved.

• Which gcc to use (there are a couple of different versions that work. Forum members have gotten it to work with 4.4.1, which is the version I use for my Fluent Interop project as well)
• Be sure to download the right version of gcc from CodeSourcery, not the GNU site
• Be sure to move the gcc binaries from their default install location to some short name without spaces. I use c:\gcc441

There are probably more. When I was figuring out how to build the firmware, I gathered my little recipe from these three threads:

http://forums.netdui...e-build-issues/
http://forums.netdui...are-with-gcc-44
http://forums.netdui...-v410-update-5/

If I had time, I might try to carefully write up a step-by-step process for doing so. A lot of others have done all the hard work, but I still believe the information is not nicely collected in a foolproof step-by-step recipe.

[Miha]

If I had time, I might try to carefully write up a step-by-step process for doing so. A lot of others have done all the hard work, but I still believe the information is not nicely collected in a foolproof step-by-step recipe.

Corey, I'll try provided links and, if I succeed, I will write a step by step guide how I did it.

Although, since I had it working with msbuild prior to juggling with Solution Wizard, I think I'll have to reinstall platform kit anyway.

Any pointers on how to "add features" to netduino project using the gcc path? (namely, the drivers for KS108B I referenced in my post)? This is the sole reason I wanted to use Solution Wizard.

Thanks,
Miha.

[Corey Kosak]

Although, since I had it working with msbuild prior to juggling with Solution Wizard, I think I'll have to reinstall platform kit anyway.

I doubt it was actually "working" before. More likely, you weren't actually rebuilding the Netduino firmware, either because the source files didn't change (and you were reusing whatever binaries were there before), or because you issued the wrong msbuild command.

msbuild is just a build system, not a compiler. You should think of it more like the Unix "make" command. Your actions with the Solution Wizard probably didn't break anything; more likely they touched some files which caused the build system to want to rebuild more things, which exposed whatever script bugs come up when trying to use VS10 to build.

If you're not using a command line like "msbuild solutions\netduino\dotnetmf.proj /p:flavor=release", then you're probably not actually rebuilding the firmware.

I really do believe the best way for me to help would be to provide soup-to-nuts instructions. One of these days I'm going to write down every single involved step (on a virgin Win7 install on a virtual machine).

[Miha]

I doubt it was actually "working" before. More likely, you weren't actually rebuilding the Netduino firmware, either because the source files didn't change (and you were reusing whatever binaries were there before), or because you issued the wrong msbuild command.

It was actually compiling the netduinoplus firmware (it took a while to do so too). I didn't specify the /p switch, but ran it with defaults on the dotnetmf.proj in netduino folder.

Anyways, I'll try the gcc path and will follow up. Thanks for your time!

Miha

[Miha]

OK, I tried the gcc route. I tried with 4.5.x, 4.4x, 4.2.3 and finally settled on 4.2.1 version of CodeSourcery.

I've got two errors to cover:
One related to CreateSymDef command not being found (which does not exist in the directory where the build scripts are looking for it) and another related to linking:

c:\gcc\bin\arm-none-eabi-ld.exe: C:\MicroFrameworkPK_v4_1\BuildOutput\THUMB\GCC4.2\le\FLASH\release\NetduinoPlus\bin\tin
yclr.axf section ER_FLASH will not fit in region LR_FLASH
c:\gcc\bin\arm-none-eabi-ld.exe: region LR_FLASH overflowed by 32912 bytes.

I solved the first issue by copying the file from C:\MicfroframeworkPK_V4_1\tools\bin. The second issue, I'm solving for the past hour, trying different solutions based on posts around here.

The last settings I've tried are from this post.

And I'm still getting

c:\gcc\bin\arm-none-eabi-ld.exe: region LR_FLASH overflowed by 32912 bytes

I did a /t:Rebuild, FWIW.

Pointers appreciated.

[Chris Walker]

If you're not using a command line like "msbuild solutions\netduino\dotnetmf.proj /p:flavor=release", then you're probably not actually rebuilding the firmware.

Very true. And actually, unless you're using the "/t:rebuild" command-line parameter, then you're only "diff building" the firmware, not rebuilding it.

When starting out building custom firmware, I always recommend:
C:\MicroFrameworkPK_v4_1\> setenv_rvds4.0.cmd "c:\program files\arm" <-- use compiler-specific batch file and your path
C:\MicroFrameworkPK_v4_1\> msbuild solutions\netduino\dotnetmf.proj /p:flavor=release /t:rebuild

Chris

[Chris Walker]

Hi Miha,

So, apparently, Solution Wizard (not much of a wizard, a? ) broke my microframwork project files. I've not found anything similar on the net, and hopefully, some of you encountered something similar?

Quick tip on SolutionWizard. The Netduino firmware has a really cool feature which lets you switch the deploy/debug port between USB, COM1, and COM2 after the firmware is already deployed. SolutionWizard doesn't know how to deal with this, and chokes

To fix this, comment out the following lines of code in the Netduino project's platform_selector.h file:

    #define DEBUG_TEXT_PORT    DEFAULT_DEPLOYMENT_PORT
    #define STDIO              DEFAULT_DEPLOYMENT_PORT
    #define DEBUGGER_PORT      DEFAULT_DEPLOYMENT_PORT
    #define MESSAGING_PORT     DEFAULT_DEPLOYMENT_PORT

...and add in the following lines.

    #define DEBUG_TEXT_PORT    USB1
    #define STDIO              USB1
    #define DEBUGGER_PORT      USB1
    #define MESSAGING_PORT     USB1

When done with SolutionWizard just put it back like you found it...

You can also leave the code with fixed deployment port settings...just be sure to set the define for DEFAULT_DEPLOYMENT_PORT to the same port you're using in the fixed deployment port settings. Your choices are USB1, COM1, and COM2.

Chris

[Miha]

An update on my progress (or non-progress, unfortunately):

I'm making very little progress. I've tried 5 different versions of GCC, and I'm about to try RVDS 4.1. I've managed to compile it with GCC 4.2 and I edited scatterfiles in order to get past

region LR_FLASH overflowed by 15744 bytes

error.

I didn't know which scatter files to edit, so I've edited the ones in NativeSample and TinyCLR directories. After that, the build succeeded with only warnings.

I tried to deploy the firmware (using MF Deploy), but failed with message (Unable to deploy to device).

I erased the flash, reflashed it with SAM-BA as per instructions found here (I used TinyBooterDecompressor.bin from the BuildOutput (C:\MicroFrameworkPK_v4_1\BuildOutput\THUMB\GCC4.2\le\FLASH\release\Netduino\bin), then tried to deploy the firmware with MFDeploy again, but got the same message.

Why does this has to be so hard?

All I want is to try and build a firmware with native drivers for KS108 LCD display, so I can get it working somehow (because the port I wrote only in C# doesn't work with LCD).

What am I doing wrong? I'm nearing my wits end...

Thank you,
Miha.

[Chris Walker]

Hi Miha, If compiling with GCC, start out using the CodeSourcery version of GCC (exact version #) listed in the .NET Micro Framework release notes... That will solve most if not all of your issues... Chris

[Miha]

If compiling with GCC, start out using the CodeSourcery version of GCC (exact version #) listed in the .NET Micro Framework release notes... That will solve most if not all of your issues...

Hey Chris! I did. I used 4.2.1 - with other versions (also from CodeSourcery) I had issues (compile errors I could not resolve myself). Note that I compiled it successfully (after I changed Code_BaseAddress in a couple of scatterfiles, but I can't deploy it to ND using MF Deploy.

For start, I compiled ND firmware (although I have ND+) and was planning on moving to ND+ after I succeed with ND firmware.

I erased the flash, deployed tinybooterdecompresor.bin using SAM-BA, then tried to deploy ER_CONFIG and ER_FLASH using MF Deploy (thisi is where I got that error).

Any hints on how to proceed greatly appreciated.

Thanks,
Miha.

[CW2]

Any hints on how to proceed greatly appreciated.

If you don't mind removing some of the existing features, like FileSystem and SD card support, the following guide enables you to build the custom firmware using the latest CodeSourcery release:

• Download and install .NET Micro Framework Porting Kit 4.1 (QFE1),
• Copy C:\MicroFrameworkPK_v4_1_QFE1 to C:\NetduinoPK,
• Download Netduino firmware source (v4.1.0 update 5) and extract it over C:\NetduinoPK, overwrite all when asked,
• Download Sourcery G++ Lite 2010.09-51 for ARM EABI IA32 Windows Installer (the latest release at the time of writing),
  4.1 during installation enter "C:\GCC" in Choose Install Folder page,
  4.2 select "Do not modify PATH" in Add product to the PATH page,
• Copy C:\GCC\lib\gcc\arm-none-eabi\4.5.1\ to C:\GCC\lib\gcc\arm-none-eabi\4.2.1\ (or create directory link),
• Launch command prompt (cmd.exe),
  

  cd \NetduinoPK
  setenv_gcc C:\GCC

• Open C:\NetduinoPK\DeviceCode\pal\tinycrt\tinycrt.cpp and comment out hal_vsnprintf() function, lines 360 - 365,
• Now you can build the firmware
  

  msbuild Solutions\Netduino\dotnetmf.proj /p:Flavor=Release /v:m /m

  but it will fail
  

  C:\GCC\bin\arm-none-eabi-ld.exe: region 'LR_FLASH' overflowed by 19444 bytes

  because GCC produces code that does not fit into the flash. To make some room, remove unnecessary features in SolutionWizard:
• Open C:\NetduinoPK\Solutions\Netduino\platform_selector.h and replace DEFAULT_DEPLOYMENT_PORT with USB on lines 79-82, so it looks like
  

  #define DEBUG_TEXT_PORT    USB1
  #define STDIO              USB1
  #define DEBUGGER_PORT      USB1
  #define MESSAGING_PORT 	USB1

• Launch C:\NetduinoPK\tools\bin\SolutionWizard\SolutionWizard.exe,
  10.1 Enter "C:\NetduinoPK" into Porting Kit Directory,
  10.2 Select "Edit an existing Solution",
  10.3 Select "Netduino" in the Solution List,
  10.4 (Optionally uncheck NativeSample, PortBooter, PortBooterLoader as they are not needed to be built),
  10.5 Uncheck FileSystem, SD, DataStorage, Stream in Feature Selection,
  10.6 Verify there are no unresolved library references,
  10.7 Finish the wizard
• Build the firmware again,
  

  msbuild Solutions\Netduino\dotnetmf.proj /p:Flavor=Release /v:m /m

  now it should succeed.

Notes:

ad 2) You can use administrative install to extract the content of msi file: msiexec /a MicroFrameworkPK.msi /qb TARGETDIR=DirectoryToExtractTo.
ad 5) Alternatively, the build script files can be edited (copying libraries is the easiest way).
ad 7) Resolves compiler error related to va_list type. The other warnings ('mangling has changed') can be ignored.
ad 8) MSBuild command line parameter /v:m (verbosity minimal) significantly speeds up the build, /m (maxcpucount) enables parallel build on multi core CPUs (if available).

I hope the above guide works for you.

[Miha]

If you don't mind removing some of the existing features, like FileSystem and SD card support, the following guide enables you to build the custom firmware using the latest CodeSourcery release:

I'll give it a go right away. What about putting it on the ND? I uploaded the version of tinybootdecompressor that I build with gcc4.2 using SAM-BA. Should I replace that with another version (probably the one I will build following your guide)?

Thanks!

[CW2]

I'll give it a go right away. What about putting it on the ND? I uploaded the version of tinybootdecompressor that I build with gcc4.2 using SAM-BA. Should I replace that with another version (probably the one I will build following your guide)?

You have to replace any existing bootloader if it was built with different scatterfile or flash block configuration.

[Miha]

CW2,

• One thing I added to your procedure was a /t:rebuild parameter. The solution is now built
• I erased the flash, then used SAM-BA to upload TinyBooterDecompressor.bin
• I ran MF Deploy, and successfully pinged my Netduino
• I selected ER_CONFIG and ER_FLASH from C:\MicroFrameworkPK_v4_1\BuildOutput\THUMB\GCC4.2\le\FLASH\release\Netduino\bin\tinyclr.hex and clicked Deploy
• MF Deploy checked signature, erased sector 0x0011e000, started deploying ER_FLASH and somewhere around 75% failed with: Error: Unable to deploy to device. See screenhost.

What did I do wrong? This is the same message I got when I did a build with gcc 4.2.1 and changed scatterfile.

Did I somehow corrupt my Netduino so it doesn't accept the new firmware?

Thanks,

Miha.

[Miha]

What did I do wrong? This is the same message I got when I did a build with gcc 4.2.1 and changed scatterfile.

I replaced TinyBooterDecompressor.bin (the one I built with gcc was ~90kb) with this one, which is ~45kb. But the error is still the same.

Thanks,
Miha.

[CW2]

• MF Deploy checked signature, erased sector 0x0011e000, started deploying ER_FLASH and somewhere around 75% failed with: Error: Unable to deploy to device. See screenhost.

What did I do wrong? This is the same message I got when I did a build with gcc 4.2.1 and changed scatterfile.

Well, you did nothing wrong. The problem is that even with the features removed the firmware is still too big - now it fits into the flash memory, but there is only a portion of the flash in .NET Micro Framework configured to contain the code and the firmware does not fit into this region. You can see in MFDeploy that ER_FLASH size is 0x50ADC, while the size of 'Code' area is only 0x40000 (launch "Flash Sector Map" command in Plug-in\Debug menu and sum 'Size' value for 'Code' rows #2 (0x3C000), #3 (0x4000)). MFDeploy shows the error, because it cannot overwrite other than 'Code' blocks. Actually, it could display 'firmware is too big' warning at the beginning, because it knows the flash sector map.

Now, you could try removing other features in Solution Wizard to reduce the firmware size even more, but you'd need to remove almost everything. I will guide you through scatterfiles in the next post...

[Miha]

Now, you could try removing other features in Solution Wizard to reduce the firmware size even more, but you'd need to remove almost everything. I will guide you through scatterfiles in the next post...

Thank you very much! I appreciate it.

[CW2]

So, because the firmware is still too big to fit into .NET Micro Framework flash code regions, they must be adjusted. The flash memory layout is defined in C:\NetduinoPK\Solutions\Netduino\DeviceCode\Blockstorage\Sam7X_blockstorage\Sam7x_Bl_Config.cpp as array of BlockRange entries. The entry represents number of blocks (the size of a block is 0x2000 bytes) of specific type (bootloader, code, deployment, config etc.):

const BlockRange g_SAM7X_BS_BlockRange[] =
{
  { BlockRange::BLOCKTYPE_BOOTSTRAP       ,  0,  5 }, // ( 5- 0+1)*0x2000 = 0x0C000
  { MEMORY_BLOCKTYPE_GCC_SPECIAL_BOOTSTRAP,  6, 14 }, // (14- 6+1)*0x2000 = 0x12000
  { BlockRange::BLOCKTYPE_CODE            , 15, 44 }, // (44-15+1)*0x2000 = 0x3C000
  { MEMORY_BLOCKTYPE_GCC_SPECIAL_CODE     , 45, 46 }, // (46-45+1)*0x2000 = 0x04000
  { BlockRange::BLOCKTYPE_DEPLOYMENT      , 47, 60 }, // (60-47+1)*0x2000 = 0x1C000
  { BlockRange::BLOCKTYPE_STORAGE_A       , 61, 61 }, // (61-61+1)*0x2000 = 0x02000
  { BlockRange::BLOCKTYPE_STORAGE_B       , 62, 62 }, // (62-62+1)*0x2000 = 0x02000
  { BlockRange::BLOCKTYPE_CONFIG          , 63, 63 }  // (63-63+1)*0x2000 = 0x02000
};

The current block configuration can be retrieved via MFDeploy Flash Sector Map command in Plug-in\Debug menu:

Flash Sector Map Command
Sector    Start       Size        Usage
-----------------------------------------------
    0    0x00100000  0x0000c000   Bootstrap        // TinyBooterDecompressor
    1    0x0010c000  0x00012000   Bootstrap        // TinyBooterDecompressor
    2    0x0011e000  0x0003c000   Code             // TinyCLR (ER_FLASH)
    3    0x0015a000  0x00004000   Code             // TinyCLR (ER_FLASH), 0x40000 Total
    4    0x0015e000  0x0001c000   Deployment
    5    0x0017a000  0x00002000   Storage (A)
    6    0x0017c000  0x00002000   Storage (B)
    7    0x0017e000  0x00002000   Configuration
Flash Sector Map Complete

The default (GCC) configuration has 0x40000 bytes for Code section, but our firmware is 0x50ADC bytes - so the code blocks must be extended to accommodate 0x52000 bytes (the next integer multiple of 0x2000 block size), while leaving enough space for bootloader (TinyBooterDecompressor, size 0x165AC) and application code in Deployment section. Thus, the block start and end indices in BlockRange structure has to be modified:

const BlockRange g_SAM7X_BS_BlockRange[] =
{
  // Updated block indices - boot 0x18000, code 0x52000, deployment 0x10000
  { BlockRange::BLOCKTYPE_BOOTSTRAP       ,  0,  5 }, // ( 5- 0+1)*0x2000 = 0x0C000
  { MEMORY_BLOCKTYPE_GCC_SPECIAL_BOOTSTRAP,  6, 11 }, // (11- 6+1)*0x2000 = 0x0C000, Sum = 0x18000 (needed 0x165AC)
  { BlockRange::BLOCKTYPE_CODE            , 12, 44 }, // (44-12+1)*0x2000 = 0x42000
  { MEMORY_BLOCKTYPE_GCC_SPECIAL_CODE     , 45, 52 }, // (52-45+1)*0x2000 = 0x10000, Sum = 0x52000 (needed 0x50ADC)
  { BlockRange::BLOCKTYPE_DEPLOYMENT      , 53, 60 }, // (60-53+1)*0x2000 = 0x10000 -> 64 KiBi for application code
  { BlockRange::BLOCKTYPE_STORAGE_A       , 61, 61 }, // (61-61+1)*0x2000 = 0x02000
  { BlockRange::BLOCKTYPE_STORAGE_B       , 62, 62 }, // (62-62+1)*0x2000 = 0x02000
  { BlockRange::BLOCKTYPE_CONFIG          , 63, 63 }  // (63-63+1)*0x2000 = 0x02000
};

The BlockRange structure is shared by both TinyBooter and TinyCLR, but each application has its own copy and those must match exactly - otherwise TinyBooter may not find the CLR runtime, or an invalid memory block could be overwritten during deployment. The TinyCLR must be located at certain address, defined in C:\NetduinoPK\Solutions\Netduino\TinyCLR\scatterfile_tinyclr_gcc.xml:

 <If Name="TARGETLOCATION" In="FLASH">
  <!-- These are the original values -->
  <Set Name="Code_BaseAddress"    Value="0x0011e000"/>
  <Set Name="Deploy_BaseAddress"  Value="0x00172000"/>
  <!-- The rest is not important, it remains the same -->
</If>

Because the Code (resp. Deployment) blocks have been changed, the Code_BaseAddress (resp. Deploy_BaseAddress) values must be adjusted appropriately:

 <If Name="TARGETLOCATION" In="FLASH">
  <!-- These are the new values -->
  <Set Name="Code_BaseAddress"    Value="0x00118000"/><!-- The first Code block is #12 -->
  <Set Name="Deploy_BaseAddress"  Value="0x0016C000"/>
  <!-- The rest is not important, it remains the same -->
</If>

The value of Code_BaseAddress equals to the address of 12. block (12*0x2000 = 0x18000) plus flash memory start address (0x00100000). The value of Deploy_BaseAddress is 54. block + flash start address (it could be 53. block, 0x6A000, but there is always some spare blocks left in all scatterfiles, so I left one there too).

Note: There is a scatter file for TinyBooterDecompressor too, but no modifications are necessary - as long as the code size does not exceed 0x1e000.

Summary steps:

• Calculate number of Code blocks depending on the firmware size,
• Adjust BlockRange structure in C:\NetduinoPK\Solutions\Netduino\DeviceCode\Blockstorage\Sam7X_blockstorage\Sam7x_Bl_Config.cpp,
• Adjust Code_BaseAddress and Deploy_BaseAddress in C:\NetduinoPK\Solutions\Netduino\TinyCLR\scatterfile_tinyclr_gcc.xml,
• Build the firmware,
• Deploy TinyBooterDecompressor via SAM-BA,
• Verify TinyBooter's Flash Sector Map in MFDeploy,
• Deploy ER_FLASH and ER_CONFIG via MFDeploy.

[Miha]

CW2, thank you so much! Not only for providing step by step instructions, but also for explanation for each step. I find the scatter file explanation especially useful as it now makes much more sense. In order to deploy new version of TinyBooterDecompressor.bin, I have to erase flash. I do it by connecting 3.3V on ND to a spot near onboard LED for ~3 seconds. Is this necessary or is there a simpler way to deploy TinyBooterDecompressor? And, I want to report, that I've successfully deployed the vanilla firmware I've built (with a lot of help from you guys!). So now, I can get back to LCD tinkering and see what the heck is going on with this KS108B of mine. Thank you!!