44 replies to this topic

[endo]

Hi Netduino Support, When can we expect the firmware beta source for the Netduino plus 2? Thanks!

[Chris Walker]

Hi endo,

When can we expect the firmware beta source for the Netduino plus 2?

Just posted it a bit earlier today. You can find it on the Downloads page.

Let me know if you need anything else!

Chris

[endo]

Thanks! Note the link: http://www.netduino....plus2/specs.htm still shows coming soon. Thanks again!

[Lunddahl]

Let me know if you need anything else!

I was actually hoping the Netduino 4.2.1.0 SDK Source was posted too ?

- Ulrik

[endo]

What GCC compiler can be used for compiling this firmware? arm-2007q3-53-arm-none-eabi.exe is giving errors the target CPU does not support ARM mode. Thanks

[ziggurat29]

I'm using the 4.7.2 yagarto toolchain, but I can't complete the build right now because of function signature mismatch in
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

[Chris Walker]

Hi Dave,

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.

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).

Chris

[ziggurat29]

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__))
#endif

before 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

[Chris Walker]

I'm pretty sure that should be a == (comparison) instead of an = (assignment). And also a lesser quasi-bug:

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.

Chris

[ziggurat29]

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 bytes

and 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

[Chris Walker]

Hi Dave,

Yeah it looked minor.
Well, no need to break out any champange yet on the gcc build:

region `LR_FLASH' overflowed by 164760 bytes

and 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.

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.

Chris

[ziggurat29]

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

[ziggurat29]

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....

[Chris Walker]

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....

Quick tip: rename your HEX files to .S19 and then use ST's "DFU File Manager" utility to convert the .S19s into .DFU files.

I think that "DFU File Manager" comes with the "STDFU Tester" installer.

Chris

[CW2]

The ER_DAT is not used, you can ignore it. If you use any IDE and a hardware debugger/flasher (JTAG, SWD) , it is usually possible to flash tinyclr.axf directly (i.e. create an empty project and set tinyclr.axf as the output), or follow the instructions on the wiki to create the DFU file.

[ziggurat29]

Thanks, I look forward to bricking my NP2 this eve! JTAG - don't have any of that on-hand, alas. wiki -- oh! I'll definitely have to check that out; maybe I wasted a lot of time figuring some things out the hard way! My last concern of the moment is that my gcc tinyclr scatterfile did not have a Deploy_BaseAddress listed, and I did increase the flash area for tinyclr. I wonder if I should be concerned, or if TinyBooter now has the ability to figure that out without being rebuilt in sync with the tiny clr... -dave

[ziggurat29]

I did make a brick. well, a light brick; it was easy enough to flash back. What an odd little tool, the dfu_file_manager. I was wondering why I needed to put in an address, since all that info is in the s-files, until I realized that you must use bin files if you are going to have more than one file make up your image. sheesh. Anyway, the first burn was of the literal s-file data haha I could see all the ascii in the flash image, so /that/ didn't work! but the second, proper, one didn't either, so more work to do, alas. 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. But not a total loss; one thing I wanted was to get the map file to analyze. If someone has a map file generated from RVDS for the NP2 firmware, I would love to have it so I can study/compare in-depth. And really, if the rvds outputs a dump file like gcc does, I'd very much like that, too... In the meantime, now that I have failed, and as I slink away defeated, I at least have gained opportunity to start over with QFE1... -rave

[CW2]

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.

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).

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.

[ziggurat29]

...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!

[CW2]

...it has config at "Config_BaseAddress" Value="0x08046800" which is not aligned to any sector at all.

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.

(*) I mean instruction sets, ARM vs. THUMB, THUMB2

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).

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).