NETMF porting to custom board

I have recently been given the daunting task of putting the NETMF on a custom made board using an STM32F405RG processor. I have been using version 4.2 of the porting kit as this is the only version that produces images that do not give me any issues when I load them onto the target hardware. I plan on working out these issues after I perform a successful port with version 4.2. I have been using the stm32f discovery board (STM32F407VG) as a testing platform and have been able to successfully build the discovery solution in the porting kit. With this built solution I have successfully transferred this to the discovery board and developed a working application. I apologise if it’s inappropriate to post this here especially since I am not using a GHI board, but my issue is with porting and I believe there are experienced developers here who can help me with that. MSDN do not even have a specific forum for NETMF questions so if there is a better place to post, If someone could please point me in the right direction that would be appreciated.

I have been able to find nuggets of information peppered around the internet with regards to porting (mainly some archived posts from GHI forums, Tour d’Horizon from Oberon microsystems and the porting kit docs), however, the porting process remains quite an enigma. I have a general idea of what I must do but there are a few areas I am not sure of.

My reasoning so far:

The pin out between the processors on both boards are different. The 405 has 64 pins while the 407 has 100 pins. These pins will be assigned differently so I believe I have to modify the platform_selector.h file. I was wondering if there was any other files that need to be touched with regards to pins and peripherals?

I was wondering how the bootloader knows which usb port to use when it’s loaded up. Is this done in the peripheral/pin setup or is there a separate bootloader specific file that I need to modify?

I figure the memory map is almost identical between these 2 processors and as such I shouldn’t have to touch scatter files outlining memory information. Reading the data sheet confirms that these two processors contain 1M of flash with the same start address.

I have all the drivers for on board peripherals. I need to ascertain that placement of board support software is in C:\MicroFrameworkPK_v4_2\DeviceCode\Drivers? The on chip peripherals I am guessing are more or less the same since they are two different variants of the same processor.

I know I am missing information here, but if anyone can help me in filling in the gaps that would be greatly appreciated.

For a start, did you derive from http://netmf4stm32.codeplex.com/ ?

Personally I wouldn’t have worked on a netmf 4.2 port, I’d get the 4.3 port working.

There are lots of helpful folk here who have done this work and may provide you input

@ richoxski - Welcome.

Ask @ Brett mentioned i would also start with the 4.3 port.

You can actually compile the port with very little to possibly even no changes to get the board running.
The only difference between the 64pin and 100pin packages (405 and 407 are basically identical) is you will have extra GPIO with the 100 pin and you can assign a few more interesting pins.

Here are the main relevant files that you could / might need to change when moving between different sized flash and ram STM32F4 packages.

C:\MicroFrameworkPK_v4_3\Solutions\Discovery4\platform_selector.h
As you have guessed, this is the file that defines the pin mappings, main crystal speed and processor speed - you will want to modify this file

C:\MicroFrameworkPK_v4_3\Solutions\Discovery4\DeviceCode\Blockstorage\STM32F4\STM32F4_BlConfig.cpp
Used for defining flash layout - in your case you wont need to change this

C:\MicroFrameworkPK_v4_3\Solutions\Discovery4\DeviceCode\Init\IO_Init.cpp
Used to configure which ports are enable - will need to be changed for larger packages

C:\MicroFrameworkPK_v4_3\Solutions\Discovery4\TinyBooter\TinyBooterEntry.cpp
Used to define how a board enters bootloader - probably no change for you

C:\MicroFrameworkPK_v4_3\Solutions\Discovery4\TinyBooter\scatterfile_bootloader_mdk.xml
C:\MicroFrameworkPK_v4_3\Solutions\Discovery4\TinyCLR\scatterfile_tinyclr_mdk.xml

Used to layout RAM/Flash usage - you wont need to change this (you might need the GCC versions depending on your compiler)

C:\MicroFrameworkPK_v4_3\Solutions\Discovery4\DeviceCode\USB\usb_config.cpp
Used for setting the name of the board

Hope this helps and let us know how you get on.

4 Likes

@ brett - Yes, I merged netmf4stm32 + the repo that adds gcc support. I did get a successful build (FEZCerberus) with 4.3 by merging the base PK with the community-ports repo. I was able to flash this to the discovery but I was unable to deploy a solution because a mismatch of the mscorlib DLL between VS2013 and the netmf image. Is this possibly becasue I mixed it with community-ports?

@ Justin - Thanks for the welcome and I’m glad it supposed to be relatively simple :slight_smile: (although I feel a little bit stupid haha). These are pretty much the files I’m looking at so thats good that I’m on the right track. Although, how does the bootloader know to use a particular usb port? I wasn’t able to find a pin mapping in platform_selector.h, only information regarding number of usb ports and max queues. Also, for both the cerberus and discovery, I had to install usb drivers in order for them to be detected by MFdeploy. Does this mean I have to compile the source code from the MicroFrameworkPK_v4_3\usb subfolder and if so how? I found the instructions enigmatic.

Thanks for your help guys!!

1 Like

Actually, I shouldn’t say the instructions were enigmatic. Just that I’m not sure how to install the DDK for the usb drivers

You dont need to worry about USB as its always connected to PA11 and PA12

You need to make sure you target the same version of NETMF in VS as you have built.

Make sure that you have changed the XTAL from 12mhz to 8mhz for the discovery in platform_selector.h

All the STM based boards use WinUSB so you dont need to compile anything for USB drivers. The biggest issue you will get there is if you have the same VID and PID for all the boards. If so then VS and device manager might get their knickers in a twist. If so you just need to delete the current driver from device manage (include hidden devices) then use WinUSB as the driver.

1 Like

Justin, you live up to your title 8). My project manager has said to move onto app development using just the discovery since netmf applications are hardware agnostic, but I might still have a play around using this new information to see if I can’t get something running. I was actually able to flash the bootloader I built for the discovery onto the board but nothing happened when I plugged in the usb. I noticed that tinybooterentry.cpp for some boards turns on leds within the TinyBooter_onstatechanged method, however, when I set it up to toggle my boards leds, nothing happened. I will go with what you say and keep posting if I run into issues

Thanks for your help Justin and Brett

@ richoxski - Only in my mind am i a legend :smiley:

Make sure BOOT0 and BOOT1 are pulled low and you are using the correct value for the main XTAL

#define SYSTEM_CRYSTAL_CLOCK_HZ 8000000 // 8MHz external clock

Discovery uses 8mhz most other ports are 12mhz

1 Like

Discovery board is all good. The custom board isn’t. My supervisor on this project was able to flash this board with a test application. I will ensure xtal speed is correct and check that all pins are working as they are supposed to :). I will keep you updated.

Thanks a lot

Just a quick point on xtals, if you used the 8mhz xtal like the Discovery, then you need to use the same firmware settings as the disco board… if you used a 12mhz, you’ll need the different firmware build. From memory, with different xtals but using the same firmware with the same settings, timers will just not work correctly (things will run slower or faster than expected). So the important thing is to make sure you know what xtal your hardware has.

1 Like

With the wrong XTAL settings the board wont even be visible to Windows

2 Likes

Ahh, well I was basing the xtal settings for the custom board on the discovery board settings which is 8Mhz. I did change the platform selector file to match the custom board(12Mhz) during my first attempt at a build but maybe I forgot to set it during a later build and thats why it is unrecognised when I flash. Argh, I want to go into work to try!!!

#define SYSTEM_CLOCK_HZ 16000000
#define CLOCK_COMMON_FACTOR 1000000
#define SLOW_CLOCKS_PER_SECOND 16000000
#define SLOW_CLOCKS_TEN_MHZ_GCD 2000000
#define SLOW_CLOCKS_MILLISECOND_GCD 1000

What about these clock defines (this is a random solution file, I don’t have the source for disco or cerb on my home computer)? are these typically changed?

Cheers guys for your help

#define SYSTEM_CLOCK_HZ 168000000 // 168MHz
#define SYSTEM_CYCLE_CLOCK_HZ 168000000 // 168MHz
#define SYSTEM_APB1_CLOCK_HZ 42000000 // 42MHz
#define SYSTEM_APB2_CLOCK_HZ 84000000 // 84MHz
#define SYSTEM_CRYSTAL_CLOCK_HZ 12000000 // 12MHz external clock
#define SUPPLY_VOLTAGE_MV 3300 // 3.3V supply

#define CLOCK_COMMON_FACTOR 1000000 // GCD(SYSTEM_CLOCK_HZ, 1M)

#define SLOW_CLOCKS_PER_SECOND 1000000 // 1MHz
#define SLOW_CLOCKS_TEN_MHZ_GCD 1000000 // GCD(SLOW_CLOCKS_PER_SECOND, 10M)
#define SLOW_CLOCKS_MILLISECOND_GCD 1000 // GCD(SLOW_CLOCKS_PER_SECOND, 1k)

1 Like

@ Justin - shouldn’t this have an extra zero? as in 10000000
#define SLOW_CLOCKS_TEN_MHZ_GCD 1000000 // GCD(SLOW_CLOCKS_PER_SECOND, 10M)

@ Jay Jay - nope - its correct as is :wink:

@ Justin - Thanks Justin. I will use those settings when I build my solution

Quick question on the compiler. It states the Keil MDK so which version do we need for this. I assume the Lite version won’t be sufficient?

@ Dave McLaughlin - Hey Dave, what documentation are you referring to? I am assuming you mean the compiler for porting kit 4.3?

@ Dave McLaughlin - you are correct, mdk lite will only go upto 32k from memory so if you want to use mdk you need the full version which costs a tad more than ÂŁ2.50

For under ÂŁ2.50 you need to use GCC

1 Like

haha, never mind ;D