Netduino Plus 2 Firmware source
#1
Posted 03 December 2012 - 07:15 PM
#2
Posted 03 December 2012 - 09:06 PM
Just posted it a bit earlier today. You can find it on the Downloads page.When can we expect the firmware beta source for the Netduino plus 2?
Let me know if you need anything else!
Chris
#3
Posted 03 December 2012 - 09:17 PM
#4
Posted 04 December 2012 - 12:14 AM
Let me know if you need anything else!
I was actually hoping the Netduino 4.2.1.0 SDK Source was posted too ?
- Ulrik
#5
Posted 06 December 2012 - 04:13 PM
#6
Posted 08 December 2012 - 05:32 AM
CLR_RT_HeapCluster.cpp for HeapCluster_Initialize
It appears that TinyCLR_Runtime.h and also Execution.cpp in the source are oriented towards an older version of .netmf where HeapCluster_Initialize() took one parameter, instead of two as in the 4.2QFE2 version. It's not yet obvious to me how to correct it myself properly, but then I haven't spent any time on it yet. But otherwise there was about nine minutes of compiling happening, so thats a start.
-dave
#7
Posted 09 December 2012 - 03:34 PM
The Netduino Plus 2 firmware is based off of .NET MF 4.2 QFE1 so be sure to copy it over the 4.2 QFE1 PK (instead of 4.2 QFE2).It appears that TinyCLR_Runtime.h and also Execution.cpp in the source are oriented towards an older version of .netmf where HeapCluster_Initialize() took one parameter, instead of two as in the 4.2QFE2 version. It's not yet obvious to me how to correct it myself properly, but then I haven't spent any time on it yet. But otherwise there was about nine minutes of compiling happening, so thats a start.
Chris
#8
Posted 09 December 2012 - 11:16 PM
The Netduino Plus 2 firmware is based off of .NET MF 4.2 QFE1 so be sure to copy it over the 4.2 QFE1 PK (instead of 4.2 QFE2).
Yes, haha, at length I did figure out that. Now it seems I am down to 'scatterfile' problems, so I'll need to figure out how those work. They seem to be some sort of memory map definition for the resultant image.
I did find what seems to be a genuine bug;
* C:\Experiments\netduino\netduino_plus_2\DeviceCode\Targets\Native\STM32\DeviceCode\STM32_PWM\STM32_pwm_functions.cpp:284
I'm pretty sure that should be a == (comparison) instead of an = (assignment). And also a lesser quasi-bug:
* C:\Experiments\netduino\netduino_plus_2\DeviceCode\Targets\Native\STM32\DeviceCode\STM32_USB\STM32_usb_functions.cpp:417
for my setup, __packed is not defined, and I resolved this by adding
#if defined(__GNUC__) #define __packed __attribute__ ((__packed__)) #endifbefore that line. I say this is a quasi-bug because I somehow feel unclean about my 'fix', that there is a better place for that definition, and that maybe it should have been picked up.
Oh well, it's compiling now, which was a feat, so on to scatterflies for the moment.
-dave
#9
Posted 10 December 2012 - 12:23 AM
Good eye, Dave. Good eye. That shouldn't have any adverse effect, but we'll be sure to check it into the next revision.I'm pretty sure that should be a == (comparison) instead of an = (assignment). And also a lesser quasi-bug:
Thanks for helping us all get GCC up and running.
Chris
#10
Posted 10 December 2012 - 03:53 AM
Good eye, Dave. Good eye. That shouldn't have any adverse effect, but we'll be sure to check it into the next revision.
Thanks for helping us all get GCC up and running.
Yeah it looked minor.
Well, no need to break out any champange yet on the gcc build:
region `LR_FLASH' overflowed by 164760 bytesand I guess I have to make a scatterfile for the tinybooter from scratch, since it wasn't in the source bundle. Do I really need to make a tinybooter? Can I not just keep the existing (production) one on the flash? I'm eager to smoketest a binary built from this toolchain.
-dave
#11
Posted 10 December 2012 - 04:28 AM
No need to rebuild the TinyBooter. You can use the one that's already in flash (and much smaller, thanks to RVCT).Yeah it looked minor.
Well, no need to break out any champange yet on the gcc build:
region `LR_FLASH' overflowed by 164760 bytesand I guess I have to make a scatterfile for the tinybooter from scratch, since it wasn't in the source bundle. Do I really need to make a tinybooter? Can I not just keep the existing (production) one on the flash? I'm eager to smoketest a binary built from this toolchain.
One of the nice things about having 384KB of codespace on Netduino Plus 2 is that you can shrink that sector to 128KB/256KB and have tons of room for GCC-built firmware. If you change the flash layout (and GCC scatter file for TinyCLR) you should have room to flash the larger firmware and still have quite a bit of codespace left over.
Chris
#12
Posted 10 December 2012 - 05:03 AM
No need to rebuild the TinyBooter. You can use the one that's already in flash (and much smaller, thanks to RVCT).
One of the nice things about having 384KB of codespace on Netduino Plus 2 is that you can shrink that sector to 128KB/256KB and have tons of room for GCC-built firmware. If you change the flash layout (and GCC scatter file for TinyCLR) you should have room to flash the larger firmware and still have quite a bit of codespace left over.
groovy; one less thing to do for starter. I did change the scatterfile to accomodate the larger image (it looks like the config area is immediately after it, so I just moved that up by the needed amount. And I may be moving again, since I have a couple unresolved symbols. Some D-to-A related stuff it looks like; I don't think we even have any on this board...
-dave
#13
Posted 10 December 2012 - 06:32 PM
#14
Posted 10 December 2012 - 06:43 PM
Quick tip: rename your HEX files to .S19 and then use ST's "DFU File Manager" utility to convert the .S19s into .DFU files.at length it did build... something! It's not a dfu file like what I'm used to for flashing the firmware updates,but I have a tinyclr.axf and some sundry bin and hex files. the hex files appear to be motorola s records. I don't know if I should be concerned that my ER_DAT (bin) files is 0 bytes. Maybe we'll see later when I have access to the board....
I think that "DFU File Manager" comes with the "STDFU Tester" installer.
Chris
#15
Posted 10 December 2012 - 07:24 PM
#16
Posted 10 December 2012 - 07:58 PM
#17
Posted 11 December 2012 - 01:26 AM
#18
Posted 11 December 2012 - 08:07 AM
The [1MB] flash is divided into several areas, so if the size of TinyCRL exceeds its dedicated area size, you have to make room for it, usually by shrinking the application deployment area. There is significantly more room on Netduino Plus 2 than on Netduino/Plus/Mini, usually even GCC built firmware fits without changes, but it may depend on the version of GCC (resp. its C/C++ runtime libraries) and .NET MF features included in the build. In all likelihood you'd need to adjust the flash memory layout for GCC debug build. It is crucial that regions and addresses in scatterfile match g_STM32_BlockRangeX definitions in Solutions\NetduinoPlus2\DeviceCode\Blockstorage\STM32\STM32_BlConfig.cpp, also the bootloader must be rebuilt and reflashed, when those change (assuming the bootloader is used at all).It's not clear why I need to shrink any (deployment) code sectors; this is an RG device, so it has 1MB flash, so it seems there's a few hundred k headroom for the tiny clr.
One thing to keep in mind is that STM32F4 flash memory is organized into several sectors of different size, so you'd need to layout the .NET MF flash memory appropriately. For more detailed information please have a look at PM0081 - STM32F40xxx and STM32F41xxx Flash programming manual (.pdf).
I have managed to get GCC-built firmware working on NetduinoGo, which uses the same micro, the source code is available in my repository on BitBucket. You will not be able to use the scatterfile directly, because it is based on older version of .NET MF and there is no bootloader used, but it should help at least a little.
#19
Posted 11 December 2012 - 01:31 PM
...also the bootloader must be rebuilt and reflashed, when those change (assuming the bootloader is used at all)....
One thing to keep in mind is that STM32F4 flash memory is organized into several sectors of different size, so you'd need to layout the .NET MF flash memory appropriately....
I have managed to get GCC-built firmware working on NetduinoGo...
Thanks so much for the advice CW2; I think what I meant by being surprised about needing to shrink deployment is that, in the NP2, it appears that the deployment area is already set to be the top 384k of flash, leaving the bottom 640k for tinclr/config, etc. The rvds-built firmware is much smaller than the gcc. leaving a huge gap before risking colliding with deployment at 080a0000, so it /seemed/ I can get away without rebuilding/reflashing tinybooter.
Speaking of flash surprises, I did notice the variable sector sizes in the datashet and was surprised config was not placed in a lower, 16k sector. Moreover in the original firmware source bundle, it has config at
"Config_BaseAddress" Value="0x08046800"which is not aligned to any sector at all. This surprised me, because I would imagine that whenever you use mfdeploy to tweak values, you would be erasing a bunch of nearby stuff also in the same sector? Maybe my understanding of the use of the config sector is way off?
I definitely will take a peek at your Go project's config. Googling obviously turned up your posts many times while I was tryign to get this far, and it was most helpful.
Ultimately, I am trying to build the firmware successfully without (too many) mods, and then to add various crypto and ssl support, and also to analyze the build size issue and see if I can maybe mod the libs to reduce it. (But it is nice to see that I have a lot of headroom before I have to optimze that way). I am too poor for rvds, and I have a hard time believing gcc is that bad -- I've used it for years, but I need to prove it first, rather than speculate (hence my plea for someone's rvds linker map file).
-dave
[edit] I feel a bit naive, I think I was assuming the gcc scatterfile out of the source bundle was sane to begin with, but looking at the rvds file, /that/ one looks sane and jibes with my thinking outlaid above. Also, on a wild hare, I dumped the official firmware with dfu and Lo! and Behold! it also jibes. (I suppose I could even use its tinybooter image, maybe). So probably some more board bricking is in my future!
#20
Posted 11 December 2012 - 03:43 PM
In my experience, anything related to configuration, especially things like memory layout is better to be considered completely wrong, until proven otherwise. In case of Secret Labs firmware, RVDS files can be used as reference, they can be simply copied to their MDK counterparts (Keil MDK-ARM and ARM RVDS share the same compiler/linker, although the functionality slightly differs and they have different libraries), scatterfile for GCC is usually unusable and there are fixes needed in the build system - I have not had a chance yet to check the most recent .NET MF, but in the previous versions there are ARM libraries forced to be linked even for non-ARM platforms (*), so the firmware ends up in usage fault handler very soon....it has config at "Config_BaseAddress" Value="0x08046800" which is not aligned to any sector at all.
(*) I mean instruction sets, ARM vs. THUMB, THUMB2
I am not sure if it is still available, but there was trial version of ARM RVDS available for download, limited to 30 days or so. The main problem with GCC is the size of printf-family functions in C/C++ runtime, but the default newlib implementation can be tweaked a little bit to produce smaller code, if you are interested in this, you can have a look for example at Step 3 in this blog post. AFAIK some analysis is available in Extended GCC support thread. Personally, I have played mostly with Yagarto, but GNU Tools for ARM could be better (I think it is the only free toolchain that comes with hardware floating point support, without the need of recompiling).I am too poor for rvds, and I have a hard time believing gcc is that bad -- I've used it for years, but I need to prove it first, rather than speculate (hence my plea for someone's rvds linker map file).
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users