Main Site Documentation

Firmware for a low power STM 32F401 device


#1

Fellow developers,

I’m thinking of building a low power device using an STM 32F401XX; probably to CD or CE version. I’ve built several boards using the 32F405 and utilised the Cerberus firmware with no problems, since it uses an STM 32F405 too.

Does anyone know if the same firmware will work on the 32F401 or do I need a different one? I don’t really want to commit to a design without having all the pieces in place first.

I’ve not looked at porting kits or compiling my own firmware so this has me out of my comfort zone.

Thanks in advance.


#2

You will not be able to use the binary version of the firmware directly on the STM32F401. There are a few issues, the memory size difference would require an alternate memory layout, the speed difference will require a different PLL configuration etc. You would need a custom port, but it would not be too hard since you can use the numerous CERB ports out there and of course the Mountaineer port as a starting point.


#3

Do you have any pointers or resources that could help me? What about a compiler? What would I need?


#4

@ Jason - I had a wiki article on the old GHI wiki that a few people used to start building their own firmware using GCC, but that is gone now.

Some of the members here had put together a custom firmware for the Cerberus with build instructions. I have not look at this for a long time, but this might help with step 1 and that is getting the firmware to build.

Once you are familiar with that you can start tweaking the code for the STM32F401. I suspect that you might only need to tweak the scatter file which defines the memory layout, assuming the part you go for has enough flash memory for the build. If not then you might need to start removing functionality.

Also check codeshare I think there are one or two custom build that started out on codeshare, they might have some details on the build process etc.

Honestly it is not very complicated, I got it going the first time by just looking at the code and building a basic understanding of how things fit together. At the time I had very little experience with ARM processors and the tool chain, not that I think I am an expert now, but I knew even less then.

From memory I would have probably take the following steps initially

  1. Install GCC tool chain (I think I used yaragato at the time, later I used the tool chain maintained by ARM)
  2. Install porting kit
  3. Check out the GHI Hyda port (I started with the FEZ Hydra) and overlay it on the porting kit installation (I kept a backup of the porting kit)
  4. Used TortoiseDiff to see how the Cerberus port changed the Porting kit base code and pieced together what was needed to add new Interop operations etc.
  5. Created the GCC compatible scatter file, the GHI scatter file is for a commercial compiler. I committed this scatter file to the GHI codeplex repository so that should still be there.

Of course I did the above for the Hydra, I also later did it for the Cerb, but there was more to it, NicholasG had worked out the GCC assembler code etc. which I leveraged.

Hope that helps. Good luck!


#5

Justin used the 100MHz F411 in the radious watch. It’s more power efficeient than the 401 and has more flash and RAM.


#6

I assume Justin used a custom firmware build for that? To take advantage of the additional memory the scatter file would need to change.


#7

Yes I assume Cuno compiles it for him.


#8

I’ll take a look over the next few days and see where it gets me.

I’ll take a look at the 411 too.

Thanks all.


#9

Hi Jason, I’m looking into this too.

I still need to get my feet wet on the matter on pcb design, etc. Still stumbling, need to have a 48 hour day for the rest of the month to get to it done … hopefully x-mas gives me enough free time, to get through it …

I got a couple of nucleos for the 411 laying around and they are still in there packages.

Anyhow, I’m certainly interrested in one for the 411 with max mem/flash.

Maybe you can take a look at VisualGDB ( http://sysprogs.com ) it integrates with VS, could be of help. It is not for free but has a low price.


#10

@ PiWi - Should I be looking at the Ultimate, custom or embedded version?

Does anyone have any experience of using it to compile NETMF for the STM32F411?


#11

I would go for the 30 day trail, see what it brings and probably for ARM stuff you’ll be OK with the embedded one, that’s the way I’m gonna take … but your call of course … sorry no deep experience …

BTW, the Radius is using the STM32F401CCU6, that it’s a little bit of short mem if you wanna go NetMf …

If I had to choose, I’d go for the RE.


#12

I think I’ll probably be doing the same.

I’ll let you know what I end up doing.


#13

I’d like to know where to find src for netmf 4.3 for STM32F4. I know that Cuno was working on that, but there’s nothing public at the moment. Now that GHI has dropped Cerberus from open source this is going to be a mess.
i’d like to work on STM32F429 chip. I will spend sometime during season holidays to see how to move from 4.2 to 4.3 the netmf for stm32 code…


#14

@ dobova - Does this help, there is mention in the application note pdf of 4.3

link to pdf: http://www.st.com/st-web-ui/static/active/en/resource/technical/document/user_manual/DM00096190.pdf?s_searchtype=keyword

if this doesn’t work then try a search on st site for stm32f429 netmf …


#15

this is a thread I saved on STM32F4 community firmware
https://www.ghielectronics.com/community/forum/topic?id=11719


#16

@ WIMC - I stand corrected, the radius is using STM32F411CEU6.


#17

@ PiWi - Thank you PiWi, I’m using it on a Discovery stm32f429 board. But I need src code.

@ Brett - Oh… I missed that thread ! Thank you for the reference link ! I will chek it out.


#18

Nah, Justin has everything he needs to compile it himself 8)


#19

We didn’t have the time yet to publish our sources. I hoped that we could simply send everything to Microsoft so that they may incorporate it into their official build. Easier if you don’t have to first assemble their stuff and our stuff. Unfortunately, it will probably take a while until they are set up to accept contributions.


#20

Assumption is always a dangerous thing.

No wonder he needs a long break.