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.
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
@ 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 (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.
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.
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
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.
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.
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!!!
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?
@ 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