STM32F7 support

[Untitled86]

I've been using NETMF with STM32F4 chips for some time now. Recently my employer started designing boards with STM32F7 chips. Naturally I need to be able to support them, or ditch NETMF.

Can someone point me at the best/simplest path to "port" NETMF to this new chip?

I'm not an expert when it comes to MPUs. I've done a lot of NETMF coding in C# and a fair amount of C/CPP customizations to our firmware/runtime (mostly tweaking hardware feature drivers and moving slow bits from C# to CPP).

Of course, I will post whatever I end up with if I'm able to get this working.

Thanks!

This probably goes without adding... But NETMF is slipping into the abyss. While embedded everything is exploding NETMF isn't. Adding support for the latest STM chip (when it probably isn't a ton of work) seems like a good idea. Unless it is a ton of work, in which case, please tell me so I can dump NETMF.

[Untitled86]

@piwi1263 - I'm running at 192Mhz. And the SPI is super slow right now. If you update the CR1_BR logic I'd appreciate the fix. I've moved on to my external SDRAM. Again, using a custom board so I can't just drop in example code. :/ I'll post the SDRAM code when that's working just incase anyone else needs it.

[piwi1263]

I'll have a look at the CR1_BR and try changing a bit here or there ... but no promises on the positive outcome of that ... :smile:

[cw2]

Regarding the SPI DR access, I was wrong: 8-bit data transfer requires that the DR register is read/written via 8-bit access, otherwise data will be automagically packed into 16 bits, which will cause problems with events in case of odd sequence of frames.

[Untitled86]

@piwi1263

I just got my SDRAM working :) Next is I2C and AnalogInputs then I'll circle back and improve the SPI CR1_BR logic if you haven't by then. I'm not the world's greatest bit-shifter. I have to slowly think it through with a calculator.

I'm using an inexpensive AS4C16M16S-6TCNTR chip. 256MB of 166MHz SDRAM for ~$2. If anyone cares I can release that code now. Otherwise I'll hold off until I've made all my changes to publish the entire repo.

[piwi1263]

My rather not so successful trails on the SPI so far:

• Altering the events of things, like setting CR1, CR2, GPIO etc. -> Mostly freezes up the board to the point one has to erase all memory and do a complete TinyBooter+TinyClr burn.
• Setting the prescaler to 2 effectively does the same, no response, no ping from mfdeploy. -> Require an erase and a complete burn again.
• At the moment it is running @216 with a hardcoded prescaler of SPI_BAUDRATEPRESCALER_64

I've switch over to SPI4 to rule out any influence from to network PHY (it is using PIN A7 too). Found that out using CubeMx and @cw2 confirmed the finding, but no change, the display starts only after 3'45" no matter what I do. But it displays and keeps on being stable.

For as far as I can see (I'm not the netmf expert, so correct me if I'm wrong), the SPI code has room for improvement, initiated/deinitiating SPI at the transaction level for all cases even if the bit size and other settings are not changed at all does not speed up the process if you got a clean/pure 8bit or whatever bit size SPI usage or only perform a deinit/init if the bit size or the settings are changing.

Another question is what is the purpose of the delay for almost every transaction of 3 seconds (if I understand it correctly) and what is the hardcoded pin (16+12) used for ? And why is it only in the 8bit transaction and not in the 16bit one ?

[piwi1263]

{Update] - Removed those delays and SPI displays the few string now within 7 secs. where the driver init and the LCD clear do only take appx 250 ms and 243 ms. Where a 3X draw string takes almost 4 secs. This all running @216 MHz clock with SPI_BAUDRATEPRESCALER_16.

Back to the bit shifting with the clock & prescaler ...

[Untitled86]

@piwi1263 - :) ...Sorry. I have a beeper on B12 that's what the delay is for. I left in the debug code. Also, I'm still running at 192MHz. Do you have your devenv setup so you can step through native runtime code running on the device? I don't. So I use my scope and the beeper to see what's going on. ...I've been coding in Textpad and compiling with GCC 5.4

[Untitled86]

I'm back on the SPI speed issue now that my memory is working :) ...I'm pretty confused myself. I've got a scope setup and I'm expecting the period to change on my SPI clock when I modify the CR1_BR space. That doesn't appear to be happening.

I'd like to use something OTHER than my scope and the beeper to debug this. In the past I've used statements like this in the native code to at least print back details...

CLR_Debug::Printf("cr1: %d", (int)cr1); CLR_Debug::Flush();

Unfortunately, that isn't working for me. I'm confused as to why this is. My Platform_Selector.H has these values...

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

...I thought that meant my CLR_Debug.Printf's would go to the USB and ultimately Visual Studio's output window.

If anyone can help me sort this out it'll simplify all my future work on this F7 business.

...Such a rookie mistake. I was adding those debug statements to STM32F4_SPI_functions.cpp instead of STM32F7_SPI_functions.cpp. ...Had both open for reference. I'm leaving this comment here incase anyone else makes my stupid mistake. It's working properly now. If anyone else needs to do this be sure to add #include <TinyCLR_Runtime.h> at the top of your cpp file.

[cw2]

@Untitled86 Have you tried hal_printf() instead?

Personally, I tend to use separate transports for DebugTextPort and STDIO, such as serial (COMx) or ITM (ITM0), so debug/tracing messages do not alter timing too much.

Does your board have any debugging support? Such as Serial Wire Debug or JTAG? If yes, I would highly recommend you to get a hardware debugger - you can either use an on-board ST-LINK from Nucleo or Discovery board or ST-LINK/V2 ($20). It pays for itself almost instantly (especially if it's a commercial project).

[Untitled86]

@piwi1263

So, I simply uncommented the code that was in there for the F4 pertaining to the CR1_BR space and checked everything out. It sortof works. Here's what I did...

1) I wrote tiny C# app that increases the SPI speed in a loop. 2) I connected my scope and setup the trigger to measure the period of the SPI clock. 3) I added those CLR_Debug.Printf lines to spit out the CR1_BR values.

As you can see the speed is changing. But it's not using all the possible register values. It's only using 111, 101, 011 or 001. No 110, 000, 010, 100. So next we fix the logic. I just wanted to post this so you (and others) could see my simple process.

...My scope is cheap, don't laugh, I'm poor. And if you're wondering why that isn't a square wave, there's a resistor inline to prevent the scope's capacitance etc. from messing up my board's signals. ...In reality it should be square.

EDIT: I'm glad I posted this but I believe I was reading the CR1 incorrectly. I was using bits 2-4 for CR1_BR not bits 3-5. See m later post. I ended up writing more readable code but I believe the original code may have been fine.

[Untitled86]

@cw2

Thanks. I have a hardware debugger and JTAG pins on the board. The guy who sits next to me codes RTOS all day. Naturally he uses the JTAG. He probably could help, but he doesn't like to share and isn't a team player. Is there a doc online that walks me through setting up my netmf environment for JTAG debugging?

[piwi1263]

@cw2, @Untitled86 - I've always wondered where these printf, hal_printf were going. I've read something about a driver on mbed that can claim that output, but I haven't tried that. For native code output, debugging etc. I'm totally blind. I let it run, either it does work or if not, I'm tinkering til it works by trail and error or try a look alike native code in VisualGDB and step thru that, that'll run in VS and show register values, does step by step etc. But that just doesn't fly against the native code executed by netmf etc.

Has anyone tried this solution [http://www.carminenoviello.com/2015/03/02/how-to-use-stm32-nucleo-serial-port/] I do get the virtual com port but doesn't spit out anything.

I second that on the doc request !!!

[Untitled86]

@piwi1263

I haven't done the virtual serial port thing. About the doc, I'll write one if/when I figure this out.

Also, I'm not so sure about the original code. I got confused about the max speed of SPI2 on the F7. Anyways, I'm now using this code which is much more readable...

    if (Configuration.Clock_RateKHz <= (clock / 256))
    {
        cr1 |= SPI_CR1_BR_2 | SPI_CR1_BR_1 | SPI_CR1_BR_0;
    }
    else if (Configuration.Clock_RateKHz <= (clock / 128))
    {
        cr1 |= SPI_CR1_BR_2 | SPI_CR1_BR_1;
    }
    else if (Configuration.Clock_RateKHz <= (clock / 64))
    {
        cr1 |= SPI_CR1_BR_2 | SPI_CR1_BR_0;
    }
    else if (Configuration.Clock_RateKHz <= (clock / 32))
    {
        cr1 |= SPI_CR1_BR_2;
    }
    else if (Configuration.Clock_RateKHz <= (clock / 16))
    {
        cr1 |= SPI_CR1_BR_1 | SPI_CR1_BR_0;
    }
    else if (Configuration.Clock_RateKHz <= (clock / 8))
    {
        cr1 |= SPI_CR1_BR_1;
    }
    else if (Configuration.Clock_RateKHz <= (clock / 4))
    {
        cr1 |= SPI_CR1_BR_0;
    }
    else
    {
        //Leave the BR values at 0, that's the fastest.
    }

And these are my test results...

original_cr1: 836 | updated_cr1: 892 | Configuration.Clock_RateKHz: 93 | clock: 24000 | cr1_br 0-2: 111
original_cr1: 836 | updated_cr1: 884 | Configuration.Clock_RateKHz: 187 | clock: 24000 | cr1_br 0-2: 110
original_cr1: 836 | updated_cr1: 876 | Configuration.Clock_RateKHz: 375 | clock: 24000 | cr1_br 0-2: 101
original_cr1: 836 | updated_cr1: 868 | Configuration.Clock_RateKHz: 750 | clock: 24000 | cr1_br 0-2: 100 
original_cr1: 836 | updated_cr1: 860 | Configuration.Clock_RateKHz: 1500 | clock: 24000 | cr1_br 0-2: 011  
original_cr1: 836 | updated_cr1: 852 | Configuration.Clock_RateKHz: 3000 | clock: 24000 | cr1_br 0-2: 010  
original_cr1: 836 | updated_cr1: 844 | Configuration.Clock_RateKHz: 6000 | clock: 24000 | cr1_br 0-2: 001
original_cr1: 836 | updated_cr1: 836 | Configuration.Clock_RateKHz: 12000 | clock: 24000 | cr1_br 0-2: 000  
original_cr1: 836 | updated_cr1: 836 | Configuration.Clock_RateKHz: 24000 | clock: 24000 | cr1_br 0-2: 000  
original_cr1: 836 | updated_cr1: 836 | Configuration.Clock_RateKHz: 48000 | clock: 24000 | cr1_br 0-2: 000 

...So, everything is working as expected for me now. I suggest you copy&paste my logic. The other code was much faster, but I don't really care about an extra ms or two while configuring SPI. I really only care about my transfer rates.

[Untitled86]

So I started during the I2C ... There are a lot of changes. The I2C feature is interrupt driven, and the interrupt specific registers have moved AND have been split up. I only need the I2C for one thing, driving and DAC for a speaker that beeps. ...And I'm only using a square wave (seems to be the most annoying beep). Bottom line, I'm using GHI's SoftwareI2C and skipping the hardware feature for now.

I moved on to the Analog hardware feature. That was trivial, it's already done and tested. DAC and the WatchDog are up tomorrow.

My latest beta Analog Input and SPI code. Be sure to uncomment those features in TinyClr.Proj https://1drv.ms/u/s!AsDrOapsdMSUk75-zRQN_Mbz33WCiw

[cw2]

Regarding diagnostic output, I have added a little doc in my repo: Diagnostics and Troubleshooting.

[cw2]

@Untitled86 You've got very nice setup there! But, do yourself a favor and get ST-LINK/V2 - it's one of the most affordable units and it basically pays for itself instantly (no matter if your project is a commercial or hobby one, the productivity is increased by several orders of magnitude).

[cw2]

I have added the following topics to the Getting Started wiki page:

• Flashing STM32Fx firmware
• Diagnostics and Troubleshooting

I'll include the description of serial (COM) transport and how to view it in MFDeploy in the next update.

Any feedback, corrections, extensions etc. are welcome.

HTH

[Untitled86]

@cw2

I have purchased an ST-LINK/V2 I just haven't taken the time to figure out how to use it to debug code. Can I use Visual Studio? If not, Eclipse? What's the IDE of choice here?

For now I'll just use the Serial Wire Viewer you linked to in your Diagnostics and Troubleshooting. That's at least a start.

[Untitled86]

Wow... Ok, I'm skipping the Watchdog implementation as well. I was using this managed code for my F4 board and I like how simple it is. For anyone who's interested...

https://1drv.ms/u/s!AsDrOapsdMSUk78C25jk6mOK2JFqiw

This works on F4 and F7. Since no change was required, it doesn't make sense for me to put any effort into this feature. I'm moving on to the DAC now.

[cw2]

@Untitled86 I think you cannot use Visual Studio directly, you'd probably need VisualGDB extension, which I am afraid is not available for free.

Visual Studio Code supports debugging C++ targets via GDB and OpenOCD provides compliant interface, so it could work in a similar way like VisualGDB, but I have not tried that yet.

There are numerous IDEs for ARM embedded development, for Eclipse-based there is for example Tutorial: Using Eclipse + ST-LINK/v2 + OpenOCD to debug.

The STM32 ST-LINK utility can read registers and do single instruction steps, on the Target menu select MCU Core.... But that is really very basic.

[Untitled86]

Analog Output is working now. Here's the pre-release if anyone cares. Again, don't forget to add this feature to your TinyClr.Proj as follows....

  <ItemGroup>
    <RequiredProjects Include="$(SPOCLIENT)\DeviceCode\Targets\Native\STM32F7\DeviceCode\STM32F7_DA\dotNetMF.proj" />
    <DriverLibs Include="STM32F7_DA.$(LIB_EXT)" />
  </ItemGroup>

https://1drv.ms/u/s!AsDrOapsdMSUk78DP6VtlA-_gSa9TA

[smaillet-ms]

Actually you could use VisualStudio if you want. It supports GDB based engines, we have support for that in the Llilum repo. Llilum also includes a C++ project system that can build C++ code as well, albeit rather clumsily at the moment. Improving that and sharing the system and VS support between NETMF and Llilum is on the radar for vNext.

[cw2]

If I understand it correctly Llium uses the same (MIEngine) support as Visual C++ for IoT Development extension (?)

I have installed this extension and with the latest OpenOCD dev version (required for STM32F7) I was able to perform some debugging on the Nucleo-144 board. But, it is very unstable and I think the NETMF memory layout has to be changed to provide space for OpenOCD work area.

It looks very promising.

[smaillet-ms]

@cw2 Yes, under the hood it is the same MIDebugEngine - we have been using it with PyOCD for Llilum but there is some support for OpenOCD as well but that wasn't used or tested heavily by the team. VsCode ultimately uses the same engine for GDB support as well. The project system for C++code in Llilum is based on very early work from the VS team that has progressed significantly since. So the goal is to loop back around on all of this common tooling for Micro Controller scenarios and unify it so it is useable for NETMF, Llilum or just plain C/C++ based systems. (I waffle back and forth on whether that warrants setting it up as it's own independent project in GitHub that is then used by the others... Thoughts from the community and hopeful future development team is welcome on that. )

[Untitled86]

I've found a problem with the SPI code I posted. The code failed to properly send/receive data when I specified a speed over ~8MHz. I seem to have solved the problem by using HAL_GPIO_Init from the ST libs. I suspect half the issue was caused by the fact that I'm using non-standard pins for SPI1. Normally it'd be PC1, PC2 and PC10. I'm using PB13, PB14 and PB15. But I also think the speed of the GPIO wasn't being set properly. I'll post again when I know more.

I'm not posting code yet because I want to polish it up a bit, but if anyone else has trouble consider adding something like this...

`

switch (Configuration.SPI_mod) {

//...Other cases here but omitted

case 1:
    RCC->APB1ENR |= RCC_APB1ENR_SPI2EN;

    GPIO_InitStructure.Pin = GPIO_PIN_13 | GPIO_PIN_14 | GPIO_PIN_15; 
    GPIO_InitStructure.Mode = ((uint32_t)0x00000002U);//GPIO_MODE_AF_PP 
    GPIO_InitStructure.Pull = ((uint32_t)0x00000000U); //GPIO_NOPULL
    GPIO_InitStructure.Speed = 0x00000003U; //GPIO_SPEED_FREQ_VERY_HIGH
    GPIO_InitStructure.Alternate = GPIO_AF5_SPI2;
    HAL_GPIO_Init(GPIOB, &GPIO_InitStructure);

    break; // enable SPI2 clock

... `

[SytechDesigns]

@Untitled86 refer to #464 for why your gpio is not set to the correct speed. With the work around in 464 added, gpio can be set to the correct speed and spi will then work fine at full speed ( pclk/2) 96Mhz clock rate.

[cw2]

@Untitled86 Also, there is something called I/O compensation cell described in the RM0385:

By default the I/O compensation cell is not used. However when the I/O output buffer speed is configured in 50 MHz or 100 MHz mode, it is recommended to use the compensation cell for slew rate control on I/O tf(IO)out)/tr(IO)out commutation to reduce the I/O noise on power supply.

[cw2]

@Untitled86 Now you can unleash the full potential of Visual Studio powerful IDE and your shiny ST-LINK/V2 - #519 :)

[Untitled86]

@cw - Thanks! I can't wait to dive into that. I've been dealing with more app issues than runtime issues (which is great). I just wanted to post back with my latest little change. ...I'm behind on updating this thread, but I plan on posting my full repo soon.

Anyways, I use code based on GHI's OSHW RTC implementation. It was designed for the F4 and would work perfectly with the F7 if BitBanding didn't change/go-away. If anyone else wants the RTC working in snap, just modify your RTC.cs and change RCC_RTCCLKCmdEnable to the following...

            public static void RCC_RTCCLKCmdEnable(UInt32 NewState)
            {
                //I put this here so I could have a simple snibbit.  It would be more consistant to place it with the rest up top. 
                uint RCC_BDCR_RTCEN = 0x00008000; 

                if (NewState != ENABLE)
                {
                    RCC_BDCR.Write(RCC_BDCR.Read() & ~RCC_BDCR_RTCEN);
                }
                else
                {
                    RCC_BDCR.Write(RCC_BDCR.Read() | RCC_BDCR_RTCEN);
                } 
            }

Originally the code was as follows, note the BB (BitBanding)...

            public static void RCC_RTCCLKCmdEnable(UInt32 NewState)
            {
                SafeToProceed(DeviceID.STM32F4Compatible);

                //Bit 15 RTCEN: RTC clock enable
                new Register(BDCR_RTCEN_BB).Write(NewState);
            }

Ultimately I want to help improve the RTC integration into the NETMF platform. I just don't know how I'm supposed to connect my code to the runtime properly.

[SytechDesigns]

@cw2 I have been working on a MF4.3 port for the M7, testing on a Nucleo board. I have LWIP basically working, but there are some timing oddities! DHCP works, then when I ping the device, there is can be a big delay in the ping responses, so that the response for request 1 does not arrive until after request 2 has been sent - so windows ping will report it as timed out - so on 4 requests, I get a 50% failure. DHCP is also a bit strange in that it tends to complete before the managed test app has been loaded, and there seems to be a usb connect disconnect sequence there as well. If I run my managed test app which implements an echo test server and run echo test on the pc ( from Pavel Banksi), then I can echo 100 messages ok, but the response time is about 7mSecs, whereas on a F4 port it is 1msec. So it basically works - but there are some timing oddities - have you come across a similar problem with your mf4.4 work, even tho 4.4 is using RTX, lwip is basically the same between 4.3 and 4.4 and I suspect this is more a M4 V M7 type issue. regards...

[cw2]

Hello, unfortunately, I have not had a chance to finish my networking port (due to family reasons), but I've got the initialization stuff working (basic driver for LAN8742 PHY on the Nucleo board), speed negotiation and connection. Now, I don't remember exactly if I am using DHCP, but most likely not (yet) and I know there is some problem further in the networking because the HTTP request fails.

There are a few things that make it a little bit challenging, because I don't have any other (M4) board with working NETMF RTOS networking implementation for reference/comparison; CMSIS RTOS (RTX) does not yet support Cortex-M7, so I had to tweak the existing M4 code and hope it works, and I shot myself in the foot with M7 instruction and data caches.

[SytechDesigns]

@cw2 - Hi, I have come to the conclusion that their might be nothing wrong with my LWIP code. It sends and receives etc. but is just a bit slow to respond. This got me thinking about something else I noticed, but filed away to look at later! Tiny booter starts and USB connects, then TinyCLR starts and usb connects - which is different behaviour than on all my other mf work. Normally tiny booter starts and passes over to tinyclr so quickly that windows does not have time to enumerate the usb in tinybooter. I am beginning to suspect that actually the M7 is running slowly - that's why Ethernet seems so 'sluggish'. I have tried turning I Cache on and off, but no real difference, other than it runs quicker ( eth response) with it on - but still slow, and as on your code comment if d cache turned on - things don't really work. ( whats the problem there?) As a sanity check I have run native code on the Nucleo boards with LwIP and also the MDK Ethernet stack - both work perfectly. I have tried with processor speed at 198Mhz and also 168Mhz - no difference. My bootstrap code is almost identical to yours - I am beginning to suspect that we are not setting up the processor correctly - any thoughts on this?

[smaillet-ms]

@SytechDesigns DHCP is actually one of the major driving reasons for the move to using an RTOS for LWIP in 4.4. In 4.3 the LWIP stack was updated (apparently fairly late in the process) and the update introduced a subtle bug that comes from how LWIP was adapted to NETMF. In general, like NETMF - LWIP can be built to work single threaded or with a multi-threaded OS. And like NETMF in a single threaded world it wants to be the owner of the single thread. Thus the NETMF port modified the LWIP stack to allow NETMF to be in charge and call into the stack via completions/continuations queues. However, the LWIP stack update include changes that assumed the calls would occur in response to a time to decrement DHCP timeouts among other things. That is the LWIP stack assumed certain calls would only happen at well known periodic intervals. However the, CLR was calling them via the continuations at random intervals including in a loop while there was nothing else to do. Thus the counters were being decremented VERY fast. This triggered DHCP requests to timeout if the server wasn't really fast to respond, furthermore the system would send out renewal requests in much shorter time periods than the server specified. (depending on the system as short as 30s). This caused a tear down of the IP address and breaks all connections. Thus, causing exceptions in .NET code. IF the code wasn't designed to handle network and interface attach/remove then the app would fail.

[SytechDesigns]

@smaillet-ms Strangely DHCP is the only thing working well! The eth mac on M7 is compatible with the M4 - so only very minor changes in the driver - just a few constants in the stm32F746.h are back to being int32 rather than int16 defines. Then just different phy - but as on the whole MF uses the 'standard' phy registers, different phys are not really a big issue. Eth on single thread works ( on the m7 mf4.3 port - but its like response to a rx'ed packet is slow. So on a ping request, it can be almost 5 seconds before the response is sent, but the response to the second request is quite quick. Same with the test with tcpip echo server on pc and managed app on device. We get 100+ echos without error, but response time from rx to tx is 160mSecs - on M4 it is <3ms. So I'm not getting data corruption, lost packets etc. just sluggish response. I need to check if entire MF is running slow, or just eth. I suspect this could be due to the piplining on the M7 making the problems you mentioned on lwip single thread, integrating with clr conflict.I suspect the rest of the MF port is working fine. I need to test more to be sure. But I think that maybe I need to move over to MF4.4 for this project. I will start with normal lwip - but ideally I want to move over to the MDK Ethernet Middle ware stack. This works well on the M7 with RTX and has a BSD interface - so will be easy to integrate into the MF PAL. But what would be helpfull are some pointers into where in the code, the clr is put onto the main RTX thread. The lwip threads are easy to find, but where clr sets up main thread and runs from it is not so obvious. I'm use to RTX projects 'main' calling KernalInitialise, then setting up other threads, and then the main thread just being put into a while forever do nothing loop! So if you could point me in the right direction in the code - it would save some searching!

[smaillet-ms]

We just implement main to call the CLR startup, nothing special. The Kernel initialize etc.. from main are not needed in CMSIS-RTX. (The startup libs have their own entry point hooks that takes care of that before calling main in Main.cpp ) For the CMSIS part that actually calls KernelInitialize see RTX_CM_lib.h around line 252

[JB16]

@cw2 are you planning on adding support for i2c for STM32F7 anytime soon? Or, could someone help answer some questions to port I2C from F4 to F7 for a c# NETMF project. Looks like the register-set for I2C is different between F4 and F7, and some of the registers don't seem to have equivalents. Simply put, I'm looking for a STM32F7_I2C_functions.cpp, or atleast want to know what to use instead of CCR as we don't seem to have an equivalent clock register on f7.

[cw2]

@JB16 I am not going to add I2C support anytime soon, sorry. F7 has two I2C control registers I2C_CR1 and I2C_CR2 - probably the easiest way is to have a look at STM32 implementation of I2C HAL driver, included in their STM32F7xx_HAL_Driver library (a downloadable part of their STM32CubeMX suite).

[JB16]

@cw2 thanks for your quick reply! Do you know of some software that puts out HAL in terms of something similar to STM32Fx_functions.cpp that can be directly used in netmf-interpreter. I already have the application part code-ready, and the netmf-interpreter HAL/PAL drivers are something that I'd prefer getting ready-to-go now.

[cw2]

@JB16 Unfortunately, I am not aware of any alternative STM32 HAL implementation that can be used directly in NETMF. Probably the closest to what you'd want is STM32CubeMX that can generate code to initialize hardware peripherals using STM's HAL library - but the interface is rather different, so it has to be modified to match NETMF interface (i.e. by adding necessary wrapper functions). Which is usually too much work, so I only use the STM's code for reference...

[patrickmealey]

@cw2 Any chance I could chat with you offline? My email is in my profile...

Thanks

[GeorgeStephens]

@Untitled86 @cw2 Has any progress been made on this/is it possible to post a repo containing what's been done so far? I'm looking doing some work based on the STM32F769 Disco

[cw2]

@GeorgeStephens Unfortunately, no progress since then, sorry.

[Spawn32]

@Untitled86 Hi Brien, Would it be possible for you to share your clock setup you used on the STM32F7 @ 12mhz ? spent 2 days trying to get my usb working, giving up :)

had a look at you github, but couldn't find it.

Would really appreciate it.

[Spawn32]

Hmm... is @Untitled86 not here anymore ? :/ Have fixed the USB but cant get SPI going...

[piwi1263]

Maybe you can have look here https://github.com/nanoframework/nf-interpreter/tree/develop/targets/CMSIS-OS/ChibiOS/ST_STM32F769I_DISCOVERY for further details on clock, spi etc.