19 replies to this topic

[nakchak]

Hi

I must be doing something wrong so if any one can give me a clue i would be much obliged.
When i build an unmodified 4.1.0.6 firmware using published source the following code yields an empty array:

public static void Main() {
 var v = VolumeInfo.GetVolumes();
 foreach(var volumeInfo in v){
  Debug.Print(volumeInfo.Name);
  Debug.Print(volumeInfo.VolumeLabel);
 }
}

Yet if i use the Secret Labs 4.1.0.6 firmware it works fine and a can access the SD card.

It seems like i must be missing something from my build (or there is a bug in the published source but that seems rather unlikely). Currently i am using the following batch file to build my firmware.

::Init a VS 2010 command prompt
call "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86_amd64
::Set environment to use Keil MDK 3.1 args
call setenv_MDK3.1.cmd C:\keil\arm
::Build ND+ solution with LWIP as TCP/IP stack
msbuild solutions\NetduinoPlus\dotnetmf.proj /p:flavor=release;tcp_ip_stack=lwip /t:rebuild -v:m /m

Can anyone shed any light on this please?

Nak.

[nakchak]

Ok the plot is thickening.

Trying to get to the bottom of this i have done the following:

• Synchronised the changes between MDK and RVDS scatter files, no difference
• Reinstalled the PK and released source for 4.1.0.6
• Obtained a demo of RVDS 4.1 to see if a change in build environment helps (compiles but cant boot, suspect this has to do with 4.0 being the latest version of RVDS 4.1 PK supports)
• Added a mapping for the MDK3.1. compiler to scatterfile_ram_functions.xml, no joy either.

However using the flash memory map function in MFDeploy i can see some differences between the production firmware and my self built one

Secret Labs Firmware (With and SD card present)

Flash Sector Map Command
 Sector	Start   	Size    	Usage
-----------------------------------------------
	0	0x00100000  0x0000c000   Bootstrap
	1	0x0010c000  0x00012000   Code
	2	0x0011e000  0x0004c000   Code
	3	0x0016a000  0x00004000   Deployment
	4	0x0016e000  0x0000c000   Deployment
	5	0x0017a000  0x00002000   Storage (A)
	6	0x0017c000  0x00002000   Storage (B)
	7	0x0017e000  0x00002000   Configuration
	8	0x00000000  0x76a00000   File System
Flash Sector Map Complete

Secret Labs Firmware (With and SD card removed)

Flash Sector Map Command
 Sector	Start   	Size    	Usage
-----------------------------------------------
	0	0x00100000  0x0000c000   Bootstrap
	1	0x0010c000  0x00012000   Code
	2	0x0011e000  0x0004c000   Code
	3	0x0016a000  0x00004000   Deployment
	4	0x0016e000  0x0000c000   Deployment
	5	0x0017a000  0x00002000   Storage (A)
	6	0x0017c000  0x00002000   Storage (B)
	7	0x0017e000  0x00002000   Configuration
Flash Sector Map Complete

As you can see when an SD card is present you get a File System entry in the Flash Map

With my firmware (ND+ 4.1.0.6 unmodified source) regardless of having an SD card present in the socket or not the filesystem entry never appears. It is not a hardware issue as when i reflash with the secret labs boot loader and firmware it works perfectly on the test board, when i use my own build nothing.

Any clues as where to look next?

Nak.

[CW2]

(or there is a bug in the published source but that seems rather unlikely).

I know for sure that the published 4.1.0.6 firmware source code is not the one used to build the official firmware, as it does not contain PWM implementation (only empty stubs). I guess it is unlikely some of the SD code or configuration is missing as well, you'd probably need to dig a little bit deeper into it and maybe compile a debug version and set a few breakpoints to figure out what could be possibly wrong. If you had RVDS version close to the one used by Secret Labs, a quick compare of result binaries could give you a clue, for example if there is a missing code section; if you are lucky there are mostly only minor differences (timestamps etc.).

[nakchak]

I know for sure that the published 4.1.0.6 firmware source code is not the one used to build the official firmware, as it does not contain PWM implementation (only empty stubs). I guess it is unlikely some of the SD code or configuration is missing as well, you'd probably need to dig a little bit deeper into it and maybe compile a debug version and set a few breakpoints to figure out what could be possibly wrong. If you had RVDS version close to the one used by Secret Labs, a quick compare of result binaries could give you a clue, for example if there is a missing code section; if you are lucky there are mostly only minor differences (timestamps etc.).

Thanks CW2

I am starting to suspect the source code as well now, although im not using RVDS it shouldnt matter as AFAIK the MDK compiler and linker are the same as those in use with RVDS. Unfortunately i do not have debug capabilities for the netduino plus, so i can only infer what differences there are, I am consistently creating a few bytes smaller firmware that the secret labs production firmware which i am suspecting is the result of missing code not a better compiler.

Which leads me back to wishing that Secret Labs maintained a publicly accessible and up to date repository, for all firmwares to date, much in the same way as i can checkout a read only snap shot of the core NETMF repository from codeplex i wish i could do the same with the ND firmwares. If nothing else with proper versioning being available to the community it would be a lot easier for community developed improvements to filter back into the main distributions, or create a culture of forking and distributing community driven features.

Nak.

[CW2]

I am starting to suspect the source code as well now, although im not using RVDS it shouldnt matter as AFAIK the MDK compiler and linker are the same as those in use with RVDS.

Although the ARM and KEIL toolchain executables are binary the same, they switch to different 'mode' based on the license. There are slight differences in behavior in the respective 'mode' (e.g. command line options) and each toolchain contains its own libraries, so the result is not the same. It would be much easier to compare for example dumps, or have at least access to the official ELF (.axf) file - maybe Chris Walker still has it

Which leads me back to wishing that Secret Labs maintained a publicly accessible and up to date repository

Perhaps we have to wait for the first annual anniversary checkin to Netduino repository in August

[nakchak]

Perhaps we have to wait for the first annual anniversary checkin to Netduino repository in August

It would be funny if it wasn't true

That said your comment about the PWM stubs got me double checking everything, and low and behold the FS_config_stubs.cpp file is an empty stub, no wonder it aint working.

(a somewhat frustrated albeit with an even greater understanding of the netmf project structure)
Nak.

[CW2]

...and low and behold the FS_config_stubs.cpp file is an empty stub, no wonder it aint working.

Oohh... nice finding. Maybe you could use FS_config.cpp from 4.1.1.0 version?

[Chris Walker]

There shouldn't be a _stubs file for the Netduino Plus project. Here's the FS_config from 4.1.0.6. Does this match what you have? C:\MicroFrameworkPK_v4_1\Solutions\NetduinoPlus\DeviceCode\FileSystem_Config_PAL\FS_config.cpp Chris

Attached Files

•  FS_config.cpp.zip   970bytes   6 downloads

[nakchak]

There shouldn't be a _stubs file for the Netduino Plus project. Here's the FS_config from 4.1.0.6. Does this match what you have?

C:\MicroFrameworkPK_v4_1\Solutions\NetduinoPlus\DeviceCode\FileSystem_Config_PAL\FS_config.cpp

Chris

Hi Chris

No, the file you posted is totally different for the 4.1.0.6 firmware i have downloaded from the site, here is what i have been trying to compile with obviously no success

/////////////////////////////////////////////////////////////////////////////////////
// Copyright (c) Microsoft Corporation.  All rights reserved.
/////////////////////////////////////////////////////////////////////////////////////
#include <tinyhal.h>

#if defined(ADS_LINKER_BUG__NOT_ALL_UNUSED_VARIABLES_ARE_REMOVED)
#pragma arm section rwdata = "g_AvailableFSInterfaces"
#endif

void FS_AddVolumes()
{
}

void FS_MountRemovableVolumes()
{
}


FILESYSTEM_INTERFACES g_AvailableFSInterfaces[] =
{
	{NULL, NULL},
};

const size_t g_InstalledFSCount = 0;

#if defined(ADS_LINKER_BUG__NOT_ALL_UNUSED_VARIABLES_ARE_REMOVED)
#pragma arm section rwdata
#endif

UPDATE
Right code compiles ok now, however the inclusion of the correct file has made the binary swell from 1.098 Mb to 1.145 Mb, and now (quite reasonably fails to deploy), which seems quite surprising as before this all compilation has been with a byte or 2 of the official secret labs
binaries I shall attempt compilation at home with the demo copy of RVDS i have downloaded although initial attempts with RVDS 4.1 produced a binary which failed to boot after deployment.

Nak.

Edited by nakchak, 20 June 2012 - 04:19 PM.

[nakchak]

Forgot to say their is also a sdconfig_stubs.cpp file in SD_CONFIG_HAL folder in the nd+ device code solution folder, but that one looks like a fully implemented file, i.e. has a © portions secret labs llc in the file header, do i need to rename it to sdconfig.cpp and update the dotNetMF.proj file to compile it?

[nakchak]

Chris would it be possible to get a copy of your working copy of the 4.1.0.6 firmware?

I can provide access to a FTP server if needed, just PM me for details

As if it would help (and i would imagine SD, Ethernet, and Motor/Servo GO modules are more deserving of your time) i would be more than happy to diff the hell out of your working copy and the source available in the downloads section and generate a patch report to get the downloadable source in sync with the source used for the precompiled 4.1.0.6 binaries. As apart from the SD card issue highlighted here CW2 has mentioned above that the downloadable source also lacks the PWM implementation and only contains stubs.

Like wise the offer is there for any future firmware source drops.

Nak.

[Chris Walker]

Hi nakchak, Do you have a copy of the 4.1.1 beta source? You should be able to pull in the SD support the same way. I'm looking back at the firmware for 4.1.0.6 and 4.1.1. It looks like AnalogInput and SD were missed in the 4.1.0.6 source but got added in later. BTW, if you have some time and want to work on getting CodePlex working, we'd love to upload all the code there on a regular basis. I can chat with you about the struggles there (largely with timeouts on large batches) if you have time... The solution is probably to move to Git. Completely optional of course, but greatly appreciated Chris

[nakchak]

Well after having added the appropriate code that Chris provided i can say there are huge differences in the size of the compiled code. Using and Evaluation copy of RVDS 4.1 i can produce a binary that is only a couple of KB larger than the stock 4.1.0.6 firmware. However using MDK the resultant binaries are much larger, at least 140Kb larger! I find this surprising as RVDS is supposed to have been superseded by MDK, so why on earth would the binaries be so much larger? Still I am determined to get this working. As i only need the SPI, USART and TCP/IP stacks for my firmware would it be possible to drop parts i dont use like PWM, analog input and I2C from my build to shrink the resultant binaries? Nak.

[CW2]

However using MDK the resultant binaries are much larger, at least 140Kb larger!

What MDK version do you use? If I remember it correctly, MDK 4.x produces output only a little bit bigger (at most a few KB) than RVDS.

As i only need the SPI, USART and TCP/IP stacks for my firmware would it be possible to drop parts i dont use like PWM, analog input and I2C from my build to shrink the resultant binaries?

Yes, you can remove features in SolutionWizard, however I am not sure how many of them you'd have to remove to gain hundreds of KB. Unfortunately, I don't know how much space a particular feature takes, but in general it is not much, you'd probably need to remove almost everything; I think SD card support is relatively big

In case you will not be able to free that much space by removing the features, you'd need to adjust flash memory layout, or if you don't mind updating the firmware via Atmel SAM-BA only, then there is a possibility to build a version without the bootloader, which frees some space ('bootstrap' blocks).

[CW2]

However using MDK the resultant binaries are much larger, at least 140Kb larger!

If you are comparing hex files (content of the official firmware .zip archives), then 140 KB is not the difference of the code, but of the textual representation. If you open hex file in MFDeploy, there is binary size shown in one of the columns, you can compare it with the size of files in your tinyclr.bin build output directory.

[nakchak]

Hi CW2 I am using MDK 3.1 as i have had no joy using 4.1, i.e. firmware compiles and will deploy (before all this SD card business any way) but fails to boot, i.e. i can access the boot loader if i hold the switch down on power up, but other wise all i get is the ACT, PWR and onboard LED lit. As i dont have access to a JATG environment for the AT91SAM7X512 i haven't been able track the issue down further, i suspect it is a memory mapping issue, but where i am not sure? As i would have thought using the bootloader that compiled at the same time would have the correct entry point mapped... It has been my experience so far that MDK produced very similar sized binaries to RVDS. The problem i have with the MDK compiled firmware is that i get a failed to deploy error in MFDeploy when i am about 95% complete on the progress bar. I have checked the binary size in MFDeploy against the files in tinclr.bin and they match exactly (392782 byte or 0x0005FE18) the one thing i have noticed is that my base address (in mfdeploy) for the ER_FLASH file is higher than the stock firmware, the stock firmware's. My firmwares base address is 0X0010E000, whilst the stock address is 0x00010C000, i assume that could well be cause of my deployment issues? Nak.

[CW2]

The problem i have with the MDK compiled firmware is that i get a failed to deploy error in MFDeploy when i am about 95% complete on the progress bar.

This usually means the firmware image is too big, i.e. bigger than the area reserved in flash.

My firmwares base address is 0X0010E000, whilst the stock address is 0x00010C000, i assume that could well be cause of my deployment issues?

Yes. This is also probably the reason your firmware does not work properly. According to the flash sector map (shown in your second post), the first code block starts at 0x10C000, so your firmware base address must be 0x10C000 as well. If it is not, you have wrong values in the scatterfile - copy scatterfile_tinyclr_rvds.xml to scatterfile_tinyclr_mdk.xml (overwrite if asked). It is also crucial the memory layout definition matches block indices in g_SAM7X_BS_BlockRange structure (\Solutions\NetduinoPlus\DeviceCode\Blockstorage\Sam7X_blockstorage\Sam7x_Bl_Config.cpp) and that you have flashed bootloader built with the exactly same configuration.

Fingers crossed.

[nakchak]

CW2 You are a God among men! Needed to increase the BLOCKTYPE_CODE range by one and everything works!!!! Thanks to Chris and CW2 on helping me get this issue resolved, i was beginning to despair of ever getting a self built firmware with SD support to work. I have just tested with code i posted in the first post of this thread and it works! , If i am ever in a bar with either of you 2 i owe you a drink! Thanks again Nak.

[nakchak]

BTW, if you have some time and want to work on getting CodePlex working, we'd love to upload all the code there on a regular basis. I can chat with you about the struggles there (largely with timeouts on large batches) if you have time... The solution is probably to move to Git. Completely optional of course, but greatly appreciated

Chris

Hi Chris

How is best to contact you regarding getting codeplex/public repo up to speed?

Nak.

[Chris Walker]

How is best to contact you regarding getting codeplex/public repo up to speed?

You have PM

Chris