I haven’t looked at 4.3 yet, but the 4.2 GCC scatterfile for the STM32F4 port was just plain wrong, last time I looked at it. But that doesn’t really matter, since you won’t be able to compile the port with GCC anyway; the 4.2 PK doesn’t have support for recent-enough GCC versions for the Cortex M4 processor. You cannot build FEZ Cerberus (STM32F4) using the 4.2 PK using GCC. You need MDK to build the Cerberus 4.2 firmware.
I’m not sure why you think you can copy NicholasG’s modified 4.3 port ontop of a 4.2 porting kit and expect it to work – you need to get rid of the 4.2 PK and install the 4.3 PK. Then copy over NicholasG’s codeshare on top of your new 4.3 PK .
Make sure to build it in release mode. I can’t fit Cerberus’s firmware on the device if it’s built in debug mode, so that may be the source of the problems.
I find the PK to be extremely verbose; if you actually read the error messages, you’ll probably be able to figure out what’s wrong. If not, post the errors here and we’ll help you. It’s fun to see your progress, but you posted this topic as a question. We’ll be able to help you much better if you give us more information.
[title]Another thing to think about:[/title]
You never specified – what are you trying to accomplish? Is there a feature that’s missing from NicolasG’s work that you need implemented? His codeshare has ready-to-roll firmware files you can load on your device without having to compile it yourself.
I don’t mean to rain on your parade, but unless you have a really good reason to build the firmware,[em] you’re probably just wasting your time[/em]. Building the firmware from source with GCC will result in bloated, slow code that won’t run as fast as GHI’s firmware, which is compiled using MDK.
In my mind, there are really only three reasons to build the firmware:
[ol]Fix an important/really annoying bug immediately without having to wait around for someone else to do it for you.
Add features that haven’t been implemented yet (like the TFT LCD controller found in the large STM32F4 microcontrollers).
Improving the performance of your application by moving certain modules into native code.[/ol]
Basically, if you don’t have any reason to modify the firmware source code, you definitely don’t have a reason to build it. And #3 is debatable; seems like most people use RLP-Lite to do time-sensitive stuff.
Just my two cents!