FMC on the stm32f429

[mensi]

Based on the module description of modm:platform:fsmc, my assumption would be that the module is meant to cover both FMC and FSMC. This assumption is reinforced by this bit of code:

    if device.has_driver("fsmc:stm32*"):
        properties["FMC"] = "FSMC"
    else:
        properties["FMC"] = "FMC"

However it seems that prepare specifically checks for if not device.has_driver("fsmc:stm32*"): only considering devices with FSMC. If we look at the f429 with an FMC peripheral for example, the driver is defined as:

<driver name="fmc" type="stm32-v1.0"/>

which doesn't seem to match.

--> Should this platform module be updated or does FMC need a dedicated one?

[salkinium]

I think this is a mistake I made when porting this driver from xpcc ages ago. I'm pretty sure that the FMC is a subset of the FSMC in functionality (S = Static?) and should be supported especially on the STM32F4.

You can change the prepare method to if not (device.has_driver("fsmc:stm32*") or device.has_driver("fmc:stm32*")): and just see if and what fails.

[mensi]

Yeah that's what I'm currently doing ;) What kind of validation would you be looking for to make the change in general?

[salkinium]

There's a "compile HAL for all devices" inside modm/test/all:

cd modm/test/all
python3 run_all.py stm32f1 stm32f4 stm32f7 stm32g4 stm32l1 stm32l4
# then to only run the failed ones again
python3 run_all.py failed

It may take a long time depending on your build machine, on the CI it takes 30mins, which isn't fast either.

[salkinium]

I mean, start with modifying an example for the STM32F4, then do the compile all, otherwise you'll go crazy.

[salkinium]

Did you make any progress or is the driver giving you issues?

[mensi]

I sadly didn't yet get around to more than setting up a huge rats nest of wires - will report back as soon as I have something.

[mensi]

I made a small bit of progress but hit a minor issue along the way: I'm using the nucleo-f429zi board for my experiments - it however looks like the pins used by the embedded stlink for the serial console collide with FMC (D8 and D9). It's of course easy to do a custom modm board, but it might also be interesting to offer an option. I don't know if there's any precedent for that - it would probably be desirable to have a consistent way of using options to configure or at least disable the serial debug console under such circumstances.

The code compiles and runs fine so far, but I wasn't yet able to get the LCD module I have here working with modm::ParallelTft<modm::TftMemoryBus16Bit>

[salkinium]

The FMC connect method will disconnect the UART pin and reconnect to FMC alternate functions, so I don't think there needs to be an lbuild option. It does need to be clearly documented that you will loose the debug port though.

I'm also not entirely sure if the STLink releases its TX pin if not used, or if it holds it high permanentely (which could be an issue right?).