@ slawek - Are you certain? The system_xxx.c file comments claim it’s running at 168. I didn’t look at the defines, just the comments.
Yes. I’m sure. The stock firmware clocked at 168 Mhz.
But in source code is clocked to 180Mhz. There is small application, showing system info and sysclock. Updated firmware shows 180 Mhz,
Download firmware
http://www.st.com/web/en/catalog/tools/PF259429
Take a look
So, there you go, I was right. The HSE frequency has little to no relevance to the system clock frequency. There’s so many PLLs, multipliers, and dividers that it makes your head swim.
cool, so the only difference between a firmware with 8MHz HSE and running at 180MHz, and a different HSE also running at 180MHz, would only need to be the HSE/PLL/multiplier setup portion… and if there was register access from netmf that might be achievable after the fact, and wouldn’t need a new firmware?
Anyway, this is somewhat arbitrary, we’re (I’m) second guessing the outcome of the work CSA/Oberon are embarking on before letting them get it done.
Hm, yes, but I don’t think it’d be safe to go the other way… i.e., if you started up on an 8mHz HSE and a 12mHz firmware, and then set it to run as if it were a 12mHz, you’d be safe.
Going the other way, starting up on a 12mHz HSE, and an 8mHz firmware, you’d be overclocked by 30% until you could get it changed. Might work, might not. Unfortunately, this is the direction you’d be wanting to go (because GHI used 12mHz crystals, I don’t know why).
It’s also worth noting that doing this would cause your USB connection to fail, as the USB clock would be incorrect, and if your application didn’t set things right, you’d have no recourse. MFDeploy could not save you; you’d be in DFU land then.
It strikes me that maybe the most simple thing to do is to have the firmware start up on the HSI oscillator, which is an internal 16mHz clock that can be used as the input to the main PLL. Then, the user application could adjust things from there.
Time to agree - any boards wanting to use these processors and milk the 180MHz setting needs to use 8MHz external oscillator ! Start this way, no problem ! 
@ Brett - Well, they don’t NEED to, but since ST used an 8mHz on the Discovery boards, it sure would simplify the porting if everyone else followed suit…
Given the (just announced) intent to release the netmf 4.3 firmware for this disco board, I’d expect the past of least resistance would be using 8MHz crystals. I can’t imagine why you’d make a decision to move to a 12MHz crystal if that then meant you had to explicitly recompile the port for 12MHz (and there is no announced details about how/if the port discussed here will or won’t be “opened” so it may well be a moot point, it would be much more effort to repeat the porting effort just because of a 12MHz crystal decision).
I’d vote for path of least resistance as there is going to be enough to do with everything else around 4.3 (eg getting all the modules etc to 4.3 (which isn’t totally hard, but displays etc are a bit harder)).
Just out of curiosity. Will the firmware for this port be released? This is super cool! But soo much more I want to add on
Can you explain?
I assumed the folks from earlier in this thread were responsible for this release form ST.
http://www.st.com/web/en/catalog/tools/PF260087
I may be wrong though. 
No, we´re not responsible for the ST release. At least, not directly: while their current release is indeed based on Oberon´s [em]NETMF for STM32[/em] port, like all Cortex-M ports of NETMF today, they have their own developers, who have written several new drivers, e.g., for LCD and gyro. We´ve integrated back their flash driver changes for the 2 MB flash memory of the F429 chips.
I don´t know whether or not STMicroelectronics plans to release their source code. We´ll see.
For [em]NETMF for STM32 4.3[/em], the 32F429IDISCOVERY board and the Mountaineer boards will be the reference hardware, for which we´ll provide solutions, with full source code.
Cuno
3 Likes
5 Likes
Awesome! Looking forward to it!
Cheers,
-Matt
The deployment tool show the source 
- rock on Oberon
2 Likes
What i find that is very interesting between ST’s Disco and Oberon’s Disco is the memory…
The ST port seems to be missing lots of ram…
Hi everybody.
We tried to play a little with new ST porting, but we didn’t succeed neither in making board visible to MFDeploy.
Despite USB device is correctly enumerated by Windows (after having disabled signature check in win8.1 x64), MFDeploy doesn’t detect 429iDisco.
Same issue arises on 2 PC, one running win8.1 x64 and on Win7 x64.
Any suggestions?
@ Innovactive - Are you powering it with Micro USB cable and using the Mini USB cable for MFDeploy?