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.

[LodinErikson]

Same here. We discussing to use the STM32F7-Disco as a base for the next development.
I read somewhere that the code for F4 should be the same for F7, but I don't know it.
I have many years of experience developing SMALL embedded systems, but a NETMF port is realy beyond my abilities.

[doingnz]

A port to STM 32F746GDISCOVERY specifically would be ideal as it is inexpensive (US $49), and includes LCD 480x272 with touch and various IO.

http://www.st.com/content/st_com/en/products/evaluation-tools/product-evaluation-tools/mcu-eval-tools/stm32-mcu-eval-tools/stm32-mcu-discovery-kits/32f746gdiscovery.html

[piwi1263]

Hi Guys, I just tried to use a 411 based image and tried it on a 746ZG doesn't fly, neither is it for the 412ZG. the latter one is even closer to the 411. Both giving me the USB Descriptor not found error. The code might be compatible but you need to rerun the compile of netmf with the appropriate dev specs. And there might be an adjustment here or there. Something alike https://github.com/NETMF/netmf-interpreter/blob/dev/Solutions/STM32F4DISCOVERY/platform_selector.h

[cw2]

I have not yet had a chance to dig deeper into particular differences between STM32F4 and F7, but in general, you'd most likely need to adjust interrupt controller configuration (usually, the number of IRQ handlers is different), memory layout (assuming F7 is superset of F4) and clock settings (in platform_selector.h mentioned above).

I have been already looking at F7 discovery board, but most likely will not get it before autumn. Unless, of course, someone convinces me otherwise :)

[josesimoes]

Because it leverages ST's official HAL for any STM32 series, PR #434 can give you a good start on that, but it still requires some work before being completely usable...

[cw2]

Well, software is usually not a problem - embedded development boards have rather low WAF, especially during the holiday season 😢

[Untitled86]

Thanks for all the posts. By the way, this amazing guy already did the port for Llilum. Doesn't that make this port to NETMF simpler?

https://github.com/roceh/stm32f7disco_llilum_lcdtest/issues/1

[smaillet-ms]

Ideally it would, however Llilum and NETMF use very different platform Abstraction layers at this point. One of the things I'm working on (and really need to commit to a complete written description) is to define a unified PAL that would allow both to share the same PAL allowing for better compare/contrast and migration as appropriate.

That said, having working code as a reference for the startup and clocks, IRQs and Pin maps certainly makes things easier.

[Untitled86]

Today I'm attempting to add support to NETMF for F7. I found the peripheral libraries online. Starting with the F4 code I moved all the code and header files in place, renamed all the folders, updated all the project files, etc. Next I updated the clock info in the Platform_selector.h from that other project. Now I'm running into differences that are more substantial. The bootstrap code for the F4 references a constant that doesn't exist in the F7 version of ST's H files. ...Anyways

I'm going to see how far I can get on my own. I'll upload my progress here and maybe someone can help me. I have about a week to do this. If I cannot make this happen I will likely be forced by my employer to switch to FreeRTOS.

This would be tragic. I've done some pretty awesome things with NETMF. One of our instruments (a UV-VIS-NIR spectrometer) uses complex math to detect how much of something is in the item being measured (chemometric models). For example if you scan a mango it can tell you how much sugar is in it. We implemented NIPLS (Non-iterative partial least squares) which works well but, because I used NETMF, I was able to allow users to write their own "plugins" using our desktop app (also C#) to implement their own math. There are lots of various "maths" that work better for different purposes. LDA for example is better at identifying things, but not as good at identifying the quantity of a given thing. ...E.g. does the mango have any sugar vs how much sugar does it have. I also gave users the ability to customize the screen and write macros (like Outlook rules) to change content dynamically. ...Things I can't do with FreeRTOS. This code is live, in production, being used successfully. I am going to be very unhappy if I have to re-write this in C/CPP just because NETMF wasn't kept current. ...I'm probably not the only one in this kind of situation.

If you're curious, this is that products page on our site (https://www.felixinstruments.com/food-science-instruments/portable-nir-analyzers/f-750-produce-quality-meter/). Unfortunately our marketing people don't highlight the features I talked about. Really they're more the type of feature that's important to have when you need it, but not really that sexy during a sale. ...The instrument is so large because the spectrometer is a very expensive Zeiss MMS1 spectrometer. That screen, it's a daylight visible memory LCD from Sharp (like E-Ink but better). I have a nice light-weight SPI driver for that, which includes very fast drawing for fonts, etc. The font characters are stored by their Unicode and the device even supports switching to Chinese/Hewbrew characters on the fly. There's a small desktop app that converts the TrueType fonts to compressed black and white bitmaps in three font sizes. And, most importantly, it renders them very quickly on the device. ...The device performs great at 168Mhz with ~120K of internal memory, and 4MB of slow external memory. The move to the F7 isn't for speed, we were motivated by the added support for cheaper faster external memory.

I've been too busy to share a lot of my code, but my employer was onboard with that the last time I spoke with him. Anyways, rant complete. The point is that I've invested too much in NETMF to give it up.

[piwi1263]

@Untitled86 There is light at the end of the tunnel, so do not abandon netmf on F7 to soon ...

[josesimoes]

@Untitled86 An awesome example of what can be done with NETMF!! Great work there. 👏

[LodinErikson]

@Untitled86 Any news on this ?
Maybe I can give you (very) little help. I have no idea how to use the SDK, github or the needed folder structure, but I have a licensed MDK pro with some experience with it.
And yes, I know my English is terrible, but I try my best... or google translate :)

[Untitled86]

Yes! I've got my board beeping and flashing LEDs! No USB or other peripherals. ...And I'm using the 4.3 codebase at the moment, just because I'm familiar with it. I plan on using 4.4 once I sort out everything.

Some key important changes are the clock (of course) and memory address changes. The F7 supports two flash modes, ITCM or AXIM. Those change the address you use to access flash memory. It's 0x08000000 for AXIM and 0x00200000 for ITCM. The boot option bytes control the mode used, along with how the board is wired. Ours was wired for ITCM. HOWEVER, in DFU mode (which is how I program boards) it ALWAYS boots to AXIM mode. So confusingly you setup your firmware for 0x002... but when you use STDFU Tester you flash to 0x080...

Also the SRAM + CCM addresses changed...
0x20000000 (64K CCM aka TCM)
0x20010000 (320K SRAM)
0x2004C000 (16K SRAM)

I'm using these settings for my clock in platform_selector...

#define SYSTEM_CLOCK_HZ 216000000
#define SYSTEM_CYCLE_CLOCK_HZ 216000000
#define SYSTEM_APB1_CLOCK_HZ 54000000
#define SYSTEM_APB2_CLOCK_HZ 108000000
#define SYSTEM_CRYSTAL_CLOCK_HZ 12000000 //Disco is 25MHz, we use 12Mhz

Now I just have to get all the peripherals working! :) No problem right? I'll post my code to my GitHub.

[Untitled86]

Ok, I've run into another wall. I must be setting the clocks up wrong. I used the F4's Bootstrap file as a starting place. There the RCC_PLLCFGR_PLLN_BITS, RCC_PLLCFGR_PLLP_BITS, RCC_PLLCFGR_PLLQ_BITS, etc. are probably all being set wrong.

I can execute this code no problem...
CPU_GPIO_EnableOutputPin((GPIO_PIN)((1 * 16) + 12), true );
CPU_GPIO_EnableOutputPin((GPIO_PIN)((1 * 16) + 12), false );

And my beeper beeps. Well, it clicks. with no delay it's barely audible. If I don't put the pin low it beeps very loudly. So that's working. But if I execute this code...
CPU_GPIO_EnableOutputPin((GPIO_PIN)((1 * 16) + 12), true );
HAL_Time_Sleep_MicroSeconds(1000);
CPU_GPIO_EnableOutputPin((GPIO_PIN)((1 * 16) + 12), false );

It hangs forever. So... If anyone wants to help, I've uploaded my bootstrap file to Onedrive...
https://1drv.ms/u/s!AsDrOapsdMSUk7ZsEG11OtNuqQzclQ

Also, any general advise if I'm headed in the wrong direction would be great.

Thanks in advance! I'll be looking for examples of how other people setup the clock. As mentioned above, I'm using a 12Mhz external clock instead of the 25Mhz used on the Disco. And my target processor speed is 216Mhz.

[cw2]

Congratulations @Untitled86 on getting F7 working!

Full disclosure: I am working on NETMF port for NUCLEO-F746ZG board, which should arrive next week...

Regarding the problem with HAL_Time_Sleep_MicroSeconds hanging up, what compiler do you use? Have a look at generated assembly listing and ensure there are THUMB instructions for IDelayLoop function (in IDelayLoop.s) generated and verify jump addresses to have thumb bit set.

[LodinErikson]

@Untitled86 Do you know "STM32CubeMX" software ?
Maybe you can compare your settings with the auto generated code.

[SytechDesigns]

@cw2 and any one else interested... did you maybe want to collaborate on the M7 disco port, I do have some\devicecode.. code already : STM32F7_Bootstrap, STM32F7_flash, STM32F7_usart,STM32F7_usb and the processor selector.h etc - most of the other peripherals are compatible with the stmf4 ( I think spi will need some minor tweaks). I do need to check with the 'source' of the code whether it is ok to publically release them, at the moment they are for internal development.

[cw2]

@SytechDesigns if you have anything that you could share, it would be much appreciated. Although I am not currently focused on the Disco board (targeting simpler Nucleo), obviously the basic components are shared and it would save a lot of work; and also having working reference source code is very valuable.

Thank you in advance.

[LodinErikson]

@SytechDesigns : Sorry but I dont understand what you mean with "M7 disco".
Is this a different hardware then the "STM32F746GDISCOVERY" and the "NUCLEO-F746ZG" ?
Or the "32F769IDISCOVERY" ?
@ALL Maybe it is better doing a port wich is based on the auto generated files from the "STM32CubeMX" software ?? I really don't know...
So much to learn...

[piwi1263]

Hi Lutz, that's actually a marvelous idea, having STM32CubeMx generate the netmf port software as well. That would certainly boost the use of netmf ... the current process of porting is soo primitive ....

[LodinErikson]

Yesterday I downloaded all(?) files, puzzled about the paths and started to build the STM32f469IDisco and... 147errors :(
I had hoped to find a Keil project by using the mdk setting, but nothing. Instead struggling with "msbuild" and 10 lines long commands and a 6MB logfile :( :(
Maybe I should go back to my "small" controllers...

[cw2]

@LodinErikson Have you followed the Getting Started guide? I can build that solution successfully with

setenv_mdk 5.05 C:\Keil\ARM
msbuild Solutions\STM32F429IDISCOVERY\dotnetmf.proj

[LodinErikson]

@cw2 Thanks for your help !
I had 2 problems.
1st : wrong path for CMSIS (not sure)
2nd : I updated Keil to newest Version V5.20 with C-Compiler Version V5.06.
With
setenv_mdk 5.06 C:\Keil\ARM
I got 148 errors :(
With
setenv_mdk 5.05 C:\Keil\ARM
everything is OK, no errors, no warnings :)
Someone else should check this. I am a beginner, maybe still my fault...

[cw2]

@LodinErikson Oh, I see - unfortunately, the version for MDK is a little bit confusing, the current value of '5.05' really means '5.05 and above' (until there are again breaking changes in the toolchain).

[Untitled86]

Yes, I'm using that for reference. I never sorted out the HAL_Time_Sleep_MicroSeconds problem. Switched to using HAL_Time_Sleep_MicroSeconds_InterruptEnabled and it worked perfectly? I've been moving my beeping and LED flashing code around to see what works. A lot of things ARE working properly. USB isn't one of them. I'm slowly going through the STM32F7_usb_functions.cpp file and comparing it with Cube and others. Hopefully I'll sort it out soon. This manual did mention that the USB wasn't SW compatible, so go figure. http://www.st.com/content/ccc/resource/technical/document/application_note/73/76/21/47/ef/d0/4c/16/DM00164538.pdf/files/DM00164538.pdf/jcr:content/translations/en.DM00164538.pdf

[LodinErikson]

@Untitled86 Any news on your project ?

[Untitled86]

@LodinErikson - Progress has been slow. So far I haven't been able to get the USB feature working properly.

I don't know how to step through the firmware code running on my device, so I've been using my oscope and toggling some GPIOs to indicate what's happening.

Currently I can see the CPU_USB_Initialize function is running (in my STM32F7_usb_functions.cpp) on bootup. It completes without error, but my USB device doesn't show up on the PC end.

Porting that from the F4 to the F7 required a lot of changes. I used various working USB F7 projects for reference. Most of them were simply renaming constants, but the structs also changed.

My old F4 code had a single struct for the USB feature. OTG_TypeDef. The newer F7 header files have that broken into several structs. USB_OTG_GlobalTypeDef, USB_OTG_DeviceTypeDef, USB_OTG_INEndpointTypeDef and USB_OTG_OUTEndpointTypeDef.

Endpoints in the old code were referenced using an array like this...
OTG->DIEP[i].INT = 0xFF; // clear endpoint interrupts
OTG->DOEP[i].INT = 0xFF;
OTG->DIEP[i].CTL = USB_OTG_DIEPCTL_EPDIS; // deactivate endpoint
OTG->DOEP[i].CTL = USB_OTG_DOEPCTL_EPDIS;

In the new code I modified that to use the new structs like this...
USB_OTG_IN_EP = ((USB_OTG_INEndpointTypeDef_) USB_OTG_FS_PERIPH_BASE + 0x900 + (i * 0x20));
USB_OTG_OUT_EP = ((USB_OTG_OUTEndpointTypeDef_) USB_OTG_FS_PERIPH_BASE + 0xB00 + (i * 0x20));

USB_OTG_IN_EP->DIEPINT = 0xFF; // clear endpoint interrupts
USB_OTG_OUT_EP->DOEPINT = 0xFF;
USB_OTG_IN_EP->DIEPCTL = USB_OTG_DIEPCTL_EPDIS; // deactivate endpoint
USB_OTG_OUT_EP->DOEPCTL = USB_OTG_DOEPCTL_EPDIS;

...I'm not sure if I made a mistake in modifying things, or what. I'm really frustrated at this point.

I also don't know if I'm initializing the clock properly. I've tested my settings by toggling a GPIO at a specific speed (e.g. 1500ms). I then monitored that GPIO using my scope and adjusted my RCC_PLLCFGR_PLLN_BITS, RCC_PLLCFGR_PLLP_BITS and RCC_PLLCFGR_PLLQ_BITS until I got exactly 1500ms on the scope. ...But I wonder if the APB/AHB clock is being initialized improperly.

I'm over my head on this. I'm not giving up, but this is really intense. Any help is appreciated.

[cw2]

Well, I have TinyBooter and bare TinyCLR for STM32F7, with the obligatory LED blinky application working (USB deployment). There are a few things I have to finish before I can publish it, so please be patient - it will come 'soon' :)

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