@Chris, but from those types of storage only BLOCKTYPE_FILESYSTEM is intended to store own data and available to managed code. We can't (or have to avoid) write our data directly to BLOCKTYPE_CONFIG or BLOCKTYPE_DEPLOYMENT.

SPI/I2C based flash is also available to managed code, but we have to solve same memory access and organization problems, plus we loose speed and RAM.

I'm not sure about BlockStorage WearLeveling driver. I will try to implement basic wear leveling in FileSystem driver. It's more reusable this way (will work with any BlockStorage drivers).

@Cuno, I saw this project, but it's just a managed extensions for managed SPI driver. And I was looking for native (FileSystem HAL) implementation.

Thanks, Chris.

I understand what BlockStorage is used for, but it's kinda strange there is no managed wrapper out-of-box. Anyway, I decided not to write native wrapper for BlockStorage + managed wrapper for native wrapper to organize direct-block-access and decided to go standard NETMF way (well, from the sources it looks to me like it's a standard way).

I'm implementing own very simple filesystem driver, like the Keil EFS one. I believe it's the best way. No need to write two wrappers, include custom libs, write storage logic in managed part. Just use File/Directory/FileStream. My external flash is just for internal use (store config, logs, sensor data, etc) and not planned to be exposed via USB (at least directly), it's not required to support common full-featured FS like FAT16 (which has lower limit of 4.1 MB, a lot of overhead and not made with low random access time and wear leveling in mind).

So, what do you think about that?

Is there any existing native implementations of simple flash-oriented FS  for NETMF?

I've added FileSystem feature firmware and configured volumes/filesystems in FS_config.cpp.

Now GetFileSystems() and GetVolumes() are working.

But I don't actually need filesystem, using low-level BlockStorage would be enough for me.

What is the best approach?

Implement driver in C#? But I' afraid loosing performance.

Using Intetop? But how can I call BlockStorage (Or SimpleStorage, or my driver) directly from C#? Or I can't do this without additional cpp wrapper?

I've implemented native BlockStorage driver for external SPI flash (defined as BlockRange::BLOCKTYPE_FILESYSTEM).

It's detected in MFDeploy (both TinyBooter and TinyCLR).

But how to use it from managed code?

VolumeInfo.GetVolumes() throws System.NotSupportedException

I think after funding $1M+ to Secret Labs there will be no alternatives to STM32 in NETMF

According to UK Mouser cheapest ST MCU can run NETMF is STM32F103RET6. I'm currently playing with this one.

But it's better to take STM32F205RET6, since F2/F4 series are widely supported by community.

What is electronic manufacturer you think is going to do for you? If you want complete custom board prototype (design, schematics, board, assembly) get ready to pay 5k+ USD. But if you already have complete project ready to manufacture, the cheapest way it to post buying request on Alibaba.com.

Finally got USB up and running! Device recognized in MFDeploy

Pinging... TinyBooter

It was USB attach pin...

#define STM32_USB_Attach_Pin_High        (16 + 16 + 13) // PC13

Tinybooter doesn't depend on anything in flash to startup, so it doesn't need config sector, right? It uses UsbDefaultConfiguration from usb_config.cpp to setup USB.

I've tried step thru code, but don't see any obvious fails. All checks passes. It reports that USB initialized fine and interrupts activated. But nothing actually happens.

I've notices that this one inside tinyhal.cpp is skipped:

#if !defined(HAL_REDUCESIZE)
    CPU_InitializeCommunication();
#endif

I rebuilt without HAL_REDUCESIZE, but seems like it's just early duplicate initialization that gets overridden later at ApplicationEntryPoint in TinyBooter.cpp.

Anyway, main USB initialization code is at CPU_USB_Initialize in STM32_usb_functions.cpp, interesting line is:

HAL_Time_Sleep_MicroSeconds(1000); // asure host recognizes dettach/attach

According to comment, I expected that PC should beep here. But it's not. Something failed silently?

There are 3 defines: STM32_USB_Attach_Pin_High, STM32_USB_Attach_Pin_Low and STM32_USB_Attach_Pin_Direct.

Are they vital to start USB? I think they only need to show "USB is connected" to user code, so they can't cause problems and I can ignore them?

I didn't find any code that initializes PA12 (USB_DP) and PA11 (USB_DM) pins. Only reset code at IO_Init.cpp:

GPIOA->CRH = 0x44444444;

Reference say that no special initialization needed for USB pins, but internet recommends to set it explicitly to alternate function open-drain, like this

GPIOA->CRH = 0x444EE444;

So, probably I'm missing proper initialization code in IO_Init.cpp?

Yes, I debug the way you describe, but only see Assembly window (see attachment) and View -> Source Browser Windows (is this one I need?) shows "No Browse Information available in ... Check - [Target-Options] [Output] [Browse Information]"

Do I need debug  (/p:flavor=debug) version? Is ST-LINK v1 enough or I need ST-LINK v2?

I tried 4.2.2 - same result.

Also, I've implemented TinyBooter in 4.3.1 for STM32Stamp - it dies at the same location, no USB connected.

Update:

Yes, adjusted scatter file (added more RAM) and rebuilt debug version of TinyBooter.

Now I can see both Symbols and Source and can step into the code. Now I just need to understand STM32 initialization code, because it's different from examples that Keil provide and STM32CubeMX codegen create.

Any useful code nav tricks here? Where can be most possible point of failure?

How to do this (check debug initialization)? Keil doesn't let me step into the code, only into assembly.

If you are talking about software USB protocol analyzer, could you recommend one?

If DeviceCode\Targets\Native\STM32 code is not changed, why shouldn't it work in NET MF 4.3? Do you think I should try first with PK 4.2.0, 4.2.1 or 4.2.2?

Did all of this several times.

 - Replaced COM1 -> USB1 in platform_selector.h

 - TinyCLR.proj replace USB stub

 - Change VID and PID (wont help, since I don't see any USB activity)

 - If it compiles, does it mean no flash space in needed? I ask, because I had to change scatter/BlConfig to fit debug version (there was errors building debug)

No USB insertion detected.

For some reason, it stucks in Events_WaitForEvents loop forever.

\DeviceCode\pal\events\events.cpp:

UINT32 Events_WaitForEvents( UINT32 sleepLevel, UINT32 WakeupSystemEvents, UINT32 Timeout_Milliseconds )
{
    NATIVE_PROFILE_PAL_EVENTS();
    // do NOT call this routine with interrupts disabled,
    // as we can die here, since flags are only set in ISRs

Does this mean MCU interrupts are not initialized properly?

I tried to replicate USB code from Solutions\MCBSTM32E, but not sure if it's done right.

Could you explain how to switch/configure USB in STM32Stamp solution?

I'm stuck again
Board still not recognized in Windows (Can't configure USB). Tried to flash my led blinky app (both .exe and .pe files) at 0x08042000, no luck.

Firmware stuck in the loop somewhere around CLR_RT_ExecutionEngine.DebuggerLoop or CLR_RT_ExecutionEngine.WaitForActivity (as least what I see when debugging in uVision with tinyclr.axf assembly).

No idea what's happening and what to do next. Anyone?

Thanks. I was able to build STM32Stamp solution myself (while waiting post moderation ).

I used BitConverter from the latest netduino 4.3.1 and modifed paths for MSVS 2013 and Keil 5.x in setenv_base.cmd and Microsoft.Spot.system.mdk.targets.

Here is the zip containing diff vs official v.4.3.1: https://dl.dropboxus...12.MDK_v5.1.zip

But now I'm little confused. STM32Stamp solution doesn't have TinyBooter. Only TinyClr. I tried to flash tinyclr.bin\ER_FLASH at 0x08000000 using ST-Link, but seems it hangs on boot. I think I'm missing some very basic here. Maybe I should flash ER_CONFIG at 0x08000000 and ER_FLASH after that at some offset?

I've noticed files like system_stm32f10x.h and stm32f10x.h in Netduino overlay. Does it mean I can use 4.3.1 PK with Netduino overlay to build for F1? Could you give some directions?

Update:

Actully I found pdf from Oberon saying tinyclr.bin\ER_FLASH to 0x08000000 and tinyclr.bin\ER_CONFIG to 0x08040000, I tried, but board still doesn't show any life signs. So I'd really like to build TinyBooter for STM32F1.

Hi guys.

I have STM32F103RET6 based board and trying to build NET MF for that.

Since the PK4.3 contains solution for STM32Stamp (which is STM32F103RET6 too) I decided that building this one is a good starting point.

I tried to build STM32Stamp solution from Porting Kit 4.3 (RTM QFE1) with Visual Studio 2013 (v12) and Keil 5.10, but I'm stuck.

I've added %VS120COMNTOOLS% to setenv_base.cmd to support MSVS2013 and added Keil 5.10 paths to \tools\Targets\Microsoft.Spot.system.mdk.targets file:

<CC      Condition="'$(COMPILER_TOOL_VERSION)'=='MDK5.10'">"$(MDK_TOOL_PATH)\armcc\bin\armcc.exe"</CC>
<CPP     Condition="'$(COMPILER_TOOL_VERSION)'=='MDK5.10'">"$(MDK_TOOL_PATH)\armcc\bin\armcc.exe"</CPP>
<AS      Condition="'$(COMPILER_TOOL_VERSION)'=='MDK5.10'">"$(MDK_TOOL_PATH)\armcc\bin\armasm.exe"</AS>
<LINK    Condition="'$(COMPILER_TOOL_VERSION)'=='MDK5.10'">"$(MDK_TOOL_PATH)\armcc\bin\armlink.exe"</LINK>
<AR      Condition="'$(COMPILER_TOOL_VERSION)'=='MDK5.10'">"$(MDK_TOOL_PATH)\armcc\bin\armar.exe"</AR>
<FROMELF Condition="'$(COMPILER_TOOL_VERSION)'=='MDK5.10'">"$(MDK_TOOL_PATH)\armcc\bin\fromelf.exe"</FROMELF>

To build I run:

cd /D f:\MicroFrameworkPK_v4_3
setenv_vs.cmd 12
setenv_mdk.cmd 5.10 f:\Keil_v5\ARM
cd f:\MicroFrameworkPK_v4_3\Solutions\STM32Stamp
msbuild /t:rebuild /p:flavor=release;memory=flash >msbuild.log

But build fails:

f:\MicroFrameworkPK_v4_3\tools\targets\Microsoft.SPOT.System.MDK.targets(276,4): error MSB3073: The command ""f:\Keil_v5\ARM\armcc\bin\armcc.exe"  --cpp  --diag_suppress 2874,111,161,550,C3011 --diag_suppress 66,161,230,1293 --split_sections  -DMDK_V3_1 -DARM_V3_1 -If:\MicroFrameworkPK_v4_3\DeviceCode -If:\MicroFrameworkPK_v4_3\DeviceCode\pal\rtip -If:\MicroFrameworkPK_v4_3\DeviceCode\pal\rtip\rtpcore -If:\MicroFrameworkPK_v4_3\devicecode\pal\rtip\tinyclr --feedback f:\MicroFrameworkPK_v4_3\tools\make\Feedback\STM32Stamp_MDK5.10.feedback -DTINYCLR_ENABLE_SOURCELEVELDEBUGGING  -DCOMPILE_THUMB2  -DVERSION_MAJOR=4 -DVERSION_MINOR=3 -DVERSION_BUILD=1 -DVERSION_REVISION=0 -DOEMSYSTEMINFOSTRING="\"Copyright Oberon microsystems, Inc.\"" -DPLATFORM_ARM_STM32Stamp  -DTARGETLOCATION_FLASH  -DLITTLE_ENDIAN  -DPLATFORM_EMULATED_FLOATINGPOINT=1 -DPLATFORM_NO_CLR_TRACE=1 -DTINYCLR_NO_APPDOMAINS=1 -DTINYCLR_NO_IL_INLINE=1   --thumb --apcs=interwork   --fpu none  --cpu Cortex-M3 --littleend  --no_debug --dwarf2 --no_debug_macros -O2 --inline -Otime --no_autoinline   -DNDEBUG  -If:\Keil_v5\ARM\RV31\INC -If:\MicroFrameworkPK_v4_3\CLR\Libraries\CorLib -If:\MicroFrameworkPK_v4_3\DeviceCode\include -If:\MicroFrameworkPK_v4_3\DeviceCode\Cores\arm -If:\MicroFrameworkPK_v4_3\Support\Include   -If:\MicroFrameworkPK_v4_3\crypto\inc  -If:\MicroFrameworkPK_v4_3\CLR\Include -If:\MicroFrameworkPK_v4_3\CLR\Libraries\CorLib -If:\MicroFrameworkPK_v4_3\CLR\Libraries\SPOT -If:\MicroFrameworkPK_v4_3\CLR\Libraries\SPOT_Hardware -If:\MicroFrameworkPK_v4_3\CLR\Libraries\SPOT_Graphics -If:\MicroFrameworkPK_v4_3\CLR\Libraries\SPOT_Net -If:\MicroFrameworkPK_v4_3\CLR\Libraries\SPOT_Net_Security -If:\MicroFrameworkPK_v4_3\Solutions\STM32Stamp -If:\MicroFrameworkPK_v4_3\devicecode\Targets\Native\STM32 -If:\MicroFrameworkPK_v4_3\DeviceCode\Cores\arm -If:\MicroFrameworkPK_v4_3\DeviceCode\Cores\arm\Include -If:\MicroFrameworkPK_v4_3\DeviceCode -If:\MicroFrameworkPK_v4_3\DeviceCode\Include -If:\MicroFrameworkPK_v4_3\DeviceCode\Targets\Native\STM32\STM32Stamp -If:\MicroFrameworkPK_v4_3\Support\Include -If:\MicroFrameworkPK_v4_3\DeviceCode\include -If:\MicroFrameworkPK_v4_3\CLR\include -If:\MicroFrameworkPK_v4_3\Crypto\inc -If:\MicroFrameworkPK_v4_3\CLR\libraries\corlib -If:\MicroFrameworkPK_v4_3\BuildOutput\THUMB2\MDK5.10\le\ANY_MEDIA\release\lib    -o f:\MicroFrameworkPK_v4_3\BuildOutput\THUMB2\MDK5.10\le\ANY_MEDIA\release\obj\CLR\Libraries\CorLib\CorLib_fastcompile.obj -c f:\MicroFrameworkPK_v4_3\CLR\Libraries\CorLib\CorLib_fastcompile.cpp " exited with code 1. [f:\MicroFrameworkPK_v4_3\CLR\Libraries\CorLib\dotnetmf.proj]

This command throws 43 warnings and 6 errors like those:

"f:\MicroFrameworkPK_v4_3\CLR\Libraries\CorLib\corlib_native_System_BitConverter.cpp", line 99: Error:  #1151: floating-point variable definition with initialiser is not permitted with --fpu=none
float input = stack.Arg0().NumericByRefConst().r4;

"f:\MicroFrameworkPK_v4_3\CLR\Libraries\CorLib\corlib_native_System_BitConverter.cpp", line 199: Error:  #1265: converting to and from floating-point type is not permitted with --fpu=none
stack.SetResult_R8(*p);

Any ideas?