Skip to content
This repository has been archived by the owner on Jun 5, 2019. It is now read-only.

[ANN] Visual Studio for NETMF Native Development #519

Open
cw2 opened this issue Sep 19, 2016 · 24 comments
Open

[ANN] Visual Studio for NETMF Native Development #519

cw2 opened this issue Sep 19, 2016 · 24 comments

Comments

@cw2
Copy link
Contributor

cw2 commented Sep 19, 2016

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()
tinybooter-bootentry

Debugging TinyClr Execute() function
tinyclr-execute

Enjoy!

@cw2 cw2 mentioned this issue Sep 19, 2016
@josesimoes
Copy link
Contributor

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

@martincalsyn
Copy link
Contributor

Nicely done! Thanks for sharing

@uscomrs
Copy link

uscomrs commented Sep 20, 2016

Well done! Thanks for sharing.

@jcherrabi
Copy link

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

@JohnySeven
Copy link

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

@smaillet-ms
Copy link
Member

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

@cw2
Copy link
Contributor Author

cw2 commented Sep 20, 2016

@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
Copy link

Awesome! Thanks for doing this.

@patrickmealey
Copy link

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
Copy link

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

image

Do a declare somewhere of
image

And than something like:
image

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
Copy link

@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
Copy link

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
Copy link
Contributor

techcap commented Oct 20, 2016

@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
Copy link

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_memory_map 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
Copy link

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___STATIC__U4__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
Copy link

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
Copy link
Contributor

doingnz commented Mar 8, 2017

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
Copy link

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
Copy link

@doingnz

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

Thanks,

Patrick

@doingnz
Copy link
Contributor

doingnz commented Mar 9, 2017

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
Copy link

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
Copy link
Contributor

doingnz commented Mar 9, 2017

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
Copy link

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

@patrickmealey
Copy link

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....

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests