cancel
Showing results for 
Search instead for 
Did you mean: 

H7 NUCLEO CubeMX-based application running. About 85% done. SW4STM32 dev continues. Custom board with H7 MCU now built. Do I need a new MCU-only (not NUCLEO) -based Cube project or will code built from original NUCLEO-based Cube project flash and run?

APagl
Associate II

More detailed description and questions:

1) MacBook Pro, CubeMX 5.4.0, SystemWorkbench 4.6.3.

2) Program for NUCLEO-H743ZI board, CubeMX generated and built. Still some development work to do ..

3) However, now have the prototype's custom board which includes the STM32H743ZITx 144-pin MCU and I would like to program the board and run the code on the custom board/MCU.

4) Can I program the custom board with the code built for the NUCLEO board? Or do I need to create new code for the MCU only/standalone... ?

5) If the code built for the NUCLEO board runs as is, great. I guess nothing else is needed.

6) However, if I need to create a new version of the code, via CubeMX, should I create it in a separate folder, as a separate Ac6/Eclipse project?

The reason I'm asking all this, is because since development continues, I need to manage changes to the code. I use git, but if I continue developing in the NUCELO project, I will have to git cherry-pick all the separate commits from the NUCLEO project to the MCU-only project. That would be untenable.

On the other hand, if create a separate git branch for the MCU-only code * in the same project * as the NUCLEO code, then any changes I make to CubeMX will re-generate many, many files, and git code management will still be a bit of a nightmare.

So, how do people normally handle the software transition from discovery board to MCU/custom board?

Thank you.

Alan

2 REPLIES 2
Piranha
Chief II

People normally write their code themselves, make code libraries and structure files and folders as they see to be appropriate for the particular project. You are the developer and you decide it, not some brainless monkeys behind CubeMX, which generates non-working bloatware anyway! When a project needs to support multiple boards, typically people introduce some BSP layer, which handles all the differences between the boards.

berendi
Principal

The IDE, toolchain or the programmer/debugger does not care at all what board is it as long as​ the MCU is the same. Selecting a nucleo or any other board just sets up some pin functions, it has no further effect on the custom board​.

If the nucleo based prototype​ is pin-compatible with the other board, there is nothing else to do. Otherwise the program should have code for the alternative configurations, either statically with #ifdef:s or runtime branches if there is a way to detect the board variant. The code generator won't assist you in this, you should code it yourself.