STM32CubeIDE not generating code correctly (Tested with STM32MP157D-DK1)

[JayDev]

Hello!  I've been using STM32 products for a while now and it appears that STM32CubeIDE is not actually generating code correctly for the STM32MP157D-DK1 board (though I suspect it will be similar with other chips/boards as well).  

I am using V1.13.2 and have tried it on both Linux and Windows, same result.  

I am accepting the default settings for everything, I can see the GPIO outputs are set for the LEDs (for instance) in the *.ioc file.  When I generate the code, it appears the code is not being generated correctly.  For instance, the declared LED pins are not being declared in main.h and the GPIO Init section enables the clocks on the port but doesn't setup any of the pins.  I suspect other IO is also being affected but this is all I have tested currently.  

I was in the process of moving some of the example projects over to an IOC project to make it easier to reconfigure peripherals but it doesn't appear there are any upsides to doing so if the code isn't going to be generated correctly (to be honest, partially generated code is almost more problematic because I won't know what's been incorrectly initialized until it fails).  

Realistically, I can do it manually, I've worked with enough projects that it should be easy enough to setup (at least for the peripherals I'm familiar with) but it seems like this is not the intended outcome of the software (unless there's a reason for this that is STM32MP1 specific that I'm unaware of).  I haven't tried to generate code with another STM device yet to see if it's just broken on my machine.  

Not sure if this is by design, a bug, or something version specific.  I thought I'd bring this up all the same.  Thanks!

[TDK]

When you assign a pin, you need to assign it to the A7 or the M4 core. It will be initialized in the code for the core it's assigned to. Right click a pin to assign.

If it's not assigned to a core, it will not be initialized.

If you're still having issues, attach an IOC file that produces the problematic code.

[JayDev]

Ah, there we go, that fixes it.  To say that's not particularly intuitive is a bit of an understatement . . . seems like that might be the type of thing worth adding to the configuration page (with items like "pin label", "default pin state", etc.  Assigning to desired core seems like something important enough to add to this section, IMO. 

Is this for GPIO specifically or are there other peripherals that need to be assigned in this manner?  I'm going through the configuration window and I'm not seeing any other peripherals that get assigned the same way (besides the obvious assignments on the categories menu on the left). 

Thanks for your help!

[TDK]

Typically, you chose the core of other peripherals such as timers, UART, etc at the time you activate them, on the left side. So it's primarily a GPIO pin thing since you pick those by clicking on them.

It's only an issue for multiprocessor chips, which are in the minority.

Agreed it could be better handled. And yes it should be displayed and selectable on the configuration page. A warning message (or error message) for pins which are not assigned to a particular core seems like the right thing to do.

[JayDev]

Well, thanks for your help with this, it was driving me crazy!  Not being able to blink an LED is a bit embarrassing . . . heh.  Have a good night!