[ANN] Visual Studio for NETMF Native Development

[cw2]

If anyone is interested, I have managed to set up Visual Studio for NETMF native development, using GCC toolchain and OpenOCD debugger, for STM32F746 Nucleo board. It allows 'F7'-style build and 'F5' debugging from within Visual Studio IDE, including breakpoints and local variables inspection.

The guide and sample .sln is available in my experimental dev-stm32f746nucleo-vs branch.

The plan is to merge it into STM32F7 port (dev-stm32f746nucleo branch) after some finishing touches and changes based on user feedback (if any). It can be easily adapted to other targets (just add and/or replace the solution directory in the project) and maybe there could be a way how to make it a bit more generic. However, the intention is NOT to replace the existing NETMF build system.

Stepping into TinyBooter BootEntry()

Debugging TinyClr Execute() function

Enjoy!

[josesimoes]

@cw2 very well done! Congrats on achieving this and also for sharing it with the community. Thank you.

[martincalsyn]

Nicely done! Thanks for sharing

[uscomrs]

Well done! Thanks for sharing.

[jcherrabi]

Great Progress, and great contribution! Thank you for your continued work and contributions :)

[JohnySeven]

@cw2 Can I buy you beer? Great stuff! :-)

[smaillet-ms]

Very, cool. Now I know who to tap for vNext/Llilum VS integration! 😉

[cw2]

@smaillet-ms I was just putting together ready-made components with a little bit of glue. But, it got me thinking about some rather interesting stuff - hopefully, The Winter is coming...

@all Thanks, I really appreciate it!

FYI, I have just pushed a bug fix - I made an embarrassing mistake that caused the ITM to stop working after reset, sorry about that 😊

[patrickmealey]

Awesome! Thanks for doing this.

[patrickmealey]

As a newbie to NETMF, I have managed to successfully build the software. I loaded TinyBooter.bin, ER_CONFIG and ER_FLASH (found in \interpreter\BuildOutput\THUMB2FP\GCC5.4\le\FLASH\release\STM32F746NUCLEO\bin) to the NUCLEO-F746ZG board. I can single step through C# code running on the Nucleo board using Visual Studio 2015.

However, when I write a C# program and attempt to use any pins, e.g., "OutputPort LED = new OutputPort(Pins.LED2, state);" I get an exception. "Exception was thrown: System.Exception."

I have the line: "using Microsoft.SPOT.Hardware.STM32F746NUCLEO;" in my program, but the other using statements refer to the default 4.4 release DLL's.

It does not appear that the build produces the executable "MicroFrameworkSDK.MSI". Is it supposed to produce this file? If not, how do I install the files produced?

This part of the build is confusing to me and, after searching for a day, I cannot find any information on the web.

Thanks in advance

[piwi1263]

Hi Patrick how about this little one, does that work ?

Do a declare somewhere of

And than something like:

this should put some light to the LEDs.

For your information, I've got an SPI driven 2.2" LCD just running fine. So, some pins do work.

[patrickmealey]

@piwi1263 Thanks, Peter, that gave me the clue as to what I was doing wrong. It works now. Turns out I was trying to create the LED multiple times without first disposing of it....

Would still like to know if the Microsoft.SPOT.Hardware.STM32F746NUCLEO is the only DLL which I need other than the stock 4.4 DLL's.

Thanks again!

[piwi1263]

The ....STM32F746NUCLEO is definately not a stock 4.4 DLL and depending on what you are trying to achieve you might even require more not stock 4.4 DLLs. To drive an ILI9341 based LCD you'd require another one that contains the driver for that particular piece of HW.

Do not forget you only build the device firmware part for an STM32F746ZG Nucleo-144 board. NOT the SDK part of netmf, that's pretty much HW neutral. Have a read at the wiki for more info.

[techcap]

@cw2 I tried to compile the branch, dev-stm32f746nucleo-vs. I opened STM32F746NUCLEO project. After building, I got error because it cannot find gcc.

Finally I modified setenv_base.cmd from 4.9 2015q1 to 5.4 2016q3. But I cannot sure if it's right.

After hit F5, it looks running but it didn't be detected on MFDeploy. After writing images, it works. Should I write images manually?

Anyway it's really awesome work. Thank you very much!!! I'll do more test on this branch.

[patrickmealey]

Successfully compiled and ran the "debug" version of this branch. Was able to load my C# application so everything fit!

I did have one issue. When attempting to start the debugger using the instructions in the guide referenced above, the following command did not work:

bin\openocd.exe -f \Solutions\STM32F746NUCLEO\vs\netmf_stm32f746nucleo.cfg

OpenOCD ran but I could not attach using Visual Studio. I received the following error message from OpenOCD:

_Info : accepting 'gdb' connection on tcp/3333 Info : device id = 0x00010001 Warn : Cannot identify target as a STM32 family. Error: auto_probe failed Error: Connect failed. Consider setting up a gdb-attach event for the target to prepare target for GDB connect, or use 'gdb_memorymap disable'. Error: attempted 'gdb' connection rejected

Visual Studio provided a pop up window with an error message as well.

Found a solution on the web. Changed the command which started OpenOCD to:

bin\openocd.exe -f \Solutions\STM32F746NUCLEO\vs\netmf_stm32f746nucleo.cfg -c "init; reset halt"

Can now single step through the source code on Visual Studio!

I am a happy developer...

[patrickmealey]

Hi All,

Could use some help with an issue. I am adding support for a micro SD card to the STM32F7NUCLEO project. The port provided by @cw2 (Thanks!) does not have this capability.

I added several projects: Stream.featureproj FileSystem.featureproj DataStorage.featureproj SPOT_IO.lib Stream.lib FS_FAT.lib fs_pal.lib FileSystem_Config_PAL SD_BL.lib

and then wrote a file:

"FileSystem_Config_STM32F746NUCLEO.cpp"

which hooks to the SPI driver to talk to the micro SD device. I based this on the Netduino code for their micro SD card.

The problem that I am having is in debugging the system.

The last call in the C# code before the C++ code is:

"uint attributes = NativeIO.GetAttributes(_fileName);" in FileStream.cs.

As nearly as I can determine this is supposed to call the routine:

"HRESULT Library_spot_io_native_Microsoft_SPOT_IO_NativeIO::GetAttributes_STATICU4__STRING(CLR_RT_StackFrame& stack)"

in the file spot_io_native_Microsoft_SPOT_IO_NativeIO.cpp.

The GDB debugger does break for other calls so I know the debugger is working, but I never see this routine executed. Instead what I get from the C# code is an immediate return with the "System.NotSupportedException".

So I guess my question is, how can I discover which routine is being called by the JITTER?

Both debuggers (C# and GDB) are both functioning and I can break on either. However, there is no visibility of what the JITTER is doing with a particular line of code.

Any help would be appreciated.

Thanks,

Patrick

[patrickmealey]

Found something that is helping a bit.

I put a breakpoint on the C# side on the NativeIO.GetAttributes call. When it hit that breakpoint, I switched to the C++ code

I put the breakpoint on :

HRESULT CLR_RT_Thread::Execute_IL( CLR_RT_StackFrame* stack );

in Interpreter.cpp.

That does break. Now I just have to trace the path taken....

Patrick

[doingnz]

What size of SD card are you using to test?

The standard NetMF SD support only goes up to 2 GB and will fail for any card above 2 GB. This due to use of 32 bit int for lengths of files in various places. The practical limit is 2 GB as 1 bit used for the sign of the int value. (2^31 gives 2GB).

Various files need to edited to fix and use 64 bit lengths. I have this working in a port to Net MF running on an ARM9 (Device Solutions Meridian HW.) and test up to 32 GB SD Cards.

Do you think your project would run on STM32 F7 Discovery HW? http://www.st.com/en/evaluation-tools/32f746gdiscovery.html

Richard

[patrickmealey]

Thanks for responding! This project is specific to the Nucleo board STM32F746ZG.

The SD card I am using to test is 8 GB. Code to increase the size I can use would be great!

However, I do not believe that is the current issue with my software as I do not call any of the routines which check the size of the SD card. I never get to that point....

After stepping through the Execute_IL routing it appears to me that the interpreter is attempting to call a routine at an invalid address. The interpreter fails in routine: CLR_RT_StackFrame::PushInline(...) in CLR_RT_StackFrame.cpp.

The particular flag which causes the failure is md-RVA. Don't really know what that means, but it causes an exception to be generated.

And, again, would be very happy to look at code to increase the size I could use for an SD card.

Thanks,

Patrick

[patrickmealey]

@doingnz

Is the support for 32 GB SD cards to be found in your NETMF fork? (https://github.com/doingnz)

Thanks,

Patrick

[doingnz]

I will have a look. Think it's not in there yet. Due to work commitments I manage main development in SVN and then contribute to git repository by copying over. I was given the sources as a diff... let me go look for those. Maybe you can do the work of merging them into the main source tree?

[patrickmealey]

I could give it a shot, although I would initially merge the changes into the F7 specific branch. We have a working I2C library for the F7 Nucleo board and I will be merging that as well when I get my SD card reader working.

[doingnz]

I reviewed the terms under which I received the suggested edits and they don't permit me to give you the sources at the moment :-(. I am required to submit the integrated sources for review/edit to a 3rd party first.

I will have to give this some thought and possibly ask them about sharing the code under similar terms to you.

[patrickmealey]

Okay, thanks for letting me the attempt. Would be very interested in looking at them!

[patrickmealey]

The continuing saga of my debug of this micro SD code continues. I used ILDASM to disassemble the NativeIO DLL (Microsoft.SPOT.IO.NativeIO.dll). That gave me no information about the GetAttributes routine..

Then I noticed a file Microsoft.SPOT.IO.dump which contains information on the DLL. The routine GetAttributes in the file has an RVA of 0xFFFF. I'm guessing that means the function is not included in the DLL.

Which means my build is missing this function. Back to the build scripts....