Mountaineer 4.3.1 Beta 3 - In-Field Updates "the Microsoft way"

[_Peter]

@munderhill

@PiWi

I can just confirm that on the 401 … it ran and still does run …

@ PiWi - what does the bottom of that board look like?

Eh, Blue … like me on a Monday … :whistle:

[Brett]

ooh, advertising spam ! @ Munderhill, that’s almost a tech foul ! ( )

[Duke_Nukem]

@Brett

@Simon from Vilnius

@ Justin - Ok, starting the countdown timer!

don’t do that to him ! He might not update his SDK like I want him to :whistle:

Which modules do you need?

[Brett]

@Duke Nukem

@Brett

@Simon from Vilnius

@ Justin - Ok, starting the countdown timer!

don’t do that to him ! He might not update his SDK like I want him to :whistle:

Which modules do you need?

mainboards

[Duke_Nukem]

Like the Octopus?

[Brett]

and Master SPI. And Blue Genie. :whistle:

[Savvkin]

@PiWi

I can just confirm that on the 401 … it ran and still does run …

@ PiWi, What netmf Porting Kit and STM32F4 implementation did you use?

@Justin

Give it 10 days or so :whistle:

@ Justin, is there any updates?

I’ve managed to run vNext TinyBooter on Nucleo-F411RE, but USART2 works only 1-way (board get trash from PC if chars sent too often). My guess that vNext ChangeSet 43297 has broken STM32F4_usart_functions.cpp driver. And probably messed clock (F411 is advertised as 100MHz, but in fact it is 104 MHz. Both is impossible to set in platform_selector.h)

[_Peter]

@Savvkin

@PiWi

I can just confirm that on the 401 … it ran and still does run …

@ PiWi, What netmf Porting Kit and STM32F4 implementation did you use?

@ Savvkin, sorry for reacting so late but what toolchain did you use to get those nucleos working or do you have a link or blog with more info ?

Oh, and for the PK, don’t know the answer to your question it was already implemented, I have it as a ‘kind of test product’ without any sources … but it would be the simplest HW I have to test a 4.4 on … although I’ve got some nucleos 411RE laying around, so I could try those as well … if I only had a proper working toolchain setup … KEIL is out of my league …

[Brett]

@Cuno

@Brett

Hi Cuno, any news on a build past Beta 3, or an update to the netmf for stm32 delta http://netmf4stm32.codeplex.com/ ?

Good timing

We should be working on an update to [em]NETMF for STM32[/em] next week. Our focus is on solving this [em]MFUpdate[/em] issue:

https://netmf.codeplex.com/workitem/2236

We need this solved both for a customer project and our Limmat platform.

We just verified that Microsoft has indeed integrated most of the code that we’ve sent them, it’s now on their Codeplex site in vNext:

https://netmf.codeplex.com/SourceControl/latest#client_vNext/DeviceCode/Targets/Native/STM32F4/processor_selector.h

As far as we can see after a quick check, they’ve copied all our STM32F4-specific files, and even modified some of them.

We’ve also made a small number of changes to the [em]portable[/em] files (as few as we could get away with). They are mostly in two categories:

• Network related issues. Here, clearly Microsoft is working an a more fundamental solution of the issues, so it makes sense that they didn’t copy our stopgap fixes.

• USB issues. These corrections would be important. The old code, still on vNext, assumes in many places that there only exists one USB controller. We’ll send Microsoft an email about this, hopefully they’ll adopt our corrections eventually.

We didn’t include the Oberon.NaCl crypto stuff, as this is still experimental code. We learned much about it, and as a result will replace one of the algorithms and in particular change the low-level C API. There is no deadline for this yet. Thus the next Mountaineer firmware update will use the current NaCl implementation and we will not yet publish its sources.

Any news Cuno on finalizing 4.3 for Mountaineer ?

[Brett]

@ Cuno, any news you can share now ?

[Cuno]

@ Brett - Unfortunately we’re not where we would like to be due to other projects. For a while, we’ve hoped to switch from our existing Codeplex repo directly to Microsoft’s GitHub repo, and have actually started to submit some files. But that repo is 4.4, and for the foreseeable future we won’t have time to make the switch to 4.4 and test and review everything as would be needed.

Fortunately, Justin was willing to publish our up-to-date sources on his new GitHub repo, to make them available to everyone:

GitHub - IngenuityMicro/NETMF-DISCO-429: NETMF 4.3.1 for the 32F429IDISCOVERY

At the moment, we hope that we now see the light at the end of the tunnel that is MFUpdate. This feature cost us much more time than we expected after our first examples were successfully running.

[Brett]

thanks for the update - so is the disco board firmware suitable for use on the Mountaineer boards without mods, or does it still require some special sauce? Edit: or is Beta 3 of a suitable quality that you’d be comfortable with using it (I’m not a production type guy, just a home hacker )

[Cuno]

@ Brett - It does require adaptation of some board-specific parameters, in particular for the memory map. But that’s just the normal differences between NETMF solutions, no secret sauce is involved. And probably these things haven’t changed from our last Codeplex release.

[B5_Fan]

So, here is what I would like to do and am wondering if it is possible.

My custom design includes a STM32F4 with NETMF 4.3.1 QEF2 using the Mountaineer MFUpdate dll. I don’t however have any on-board flash (no room). But my application is only 55K. What I would like to do is to load my new app into the lower 128K block of the application flash and tell MFUpdate to update the application from that location. Possible? Sure would be sweet if it was.