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.