Support for STM32 F0/G0 remap pins #471

chris-durand · 2020-09-16T17:37:23Z

This adds support for remapped gpio pins on small G0/F0 controllers.

@salkinium https://github.com/modm-io/modm-devices/pull/47/files breaks it. So we need to find a solution for that.

chris-durand · 2020-09-16T18:04:20Z

There is the following in the g071 device file:

      <gpio port="a" pin="9">
        <signal device-pin="c|k" device-package="u" driver="ucpd" instance="1" name="dbcc1"/>
        <signal device-pin="c|k|r" device-package="t" driver="ucpd" instance="1" name="dbcc1"/>
        <signal af="0" driver="rcc" name="mco"/>
        <signal af="1" driver="usart" instance="1" name="tx"/>
        <signal af="2" driver="tim" instance="1" name="ch2"/>
        <signal af="4" driver="spi" instance="2" name="miso"/>
        <signal af="5" driver="tim" instance="15" name="bk"/>
        <signal af="6" driver="i2c" instance="1" name="scl"/>
      </gpio>
      <gpio device-pin="c|k|r" port="a" pin="9">
        <signal device-package="i" driver="ucpd" instance="1" name="dbcc1"/>
        <signal af="0" driver="rcc" name="mco"/>
        <signal af="1" driver="usart" instance="1" name="tx"/>
        <signal af="2" driver="tim" instance="1" name="ch2"/>
        <signal af="4" driver="spi" instance="2" name="miso"/>
        <signal af="5" driver="tim" instance="15" name="bk"/>
        <signal af="6" driver="i2c" instance="1" name="scl"/>
      </gpio>

Therefore, lbuild tries to generate the A9 gpio header twice for the g071rb and fails.

salkinium · 2020-09-16T18:16:18Z

I see this is more complicated than I initially thought. I still think the device file has an issue and there should not be two A9 pins, so I'm checking this.

chris-durand · 2020-09-16T18:20:01Z

Keep in mind that this PR still has the modm-devices version from before modm-io/modm-devices#47 was merged.

salkinium · 2020-09-16T19:31:19Z

I don't think this "automatic" API works for this package, since you cannot tell which Pin GpioA9 is called for, and thus if you wanted to use A9 and A11 at the same time, your API wouldn't let you:

I think we should only add the GpioA9::remap() and GpioA11::remap() functions (analog for A10/A12) and let the user call it when necessary.

chris-durand · 2020-09-16T19:35:55Z

Yes, for these weird G0 it doesn't work. Do you know how I would enable the UCPD1_DBCC* functions on A9 and A10? I'm trying to figure out how it would be used when the normal A9/A10 pin are set to UCPD and A9/A10 are remapped onto the A11/A12 pins.

salkinium · 2020-09-16T20:03:35Z

Do you know how I would enable the UCPD1_DBCC* functions on A9 and A10?

Skimming though the UCPD section of the reference manual, I have a suspicion that they should be configured as Analog Inputs, and the analog part is connected before the digital multiplexor, thus it would make sense that they cannot be remapped in hardware.

But I couldn't find any specific information about this in the datasheet or reference manual, except this (RM0444 Rev 2):

(Interestingly the STM32G0 only has max. 8 AFs, not 16 AFs as before)

chris-durand · 2020-09-16T20:21:41Z

I played around with CubeMX and the G071RB. The UCPD1_CC pins (not remap pins) are configured as analog mode. It seems the UCPD1_DBCC functionality gets activated on the physical A9/A10 pins just by setting flags in SYSCFG and the A9/A10 mode value controls the remapped pins on the physical A11/A12 pins. When I had UCPD1_DBCC enabled on A9/A10, A11/A12 remap active and UART1 RX/TX (A9/A10 AF) on the normal A11/A12 pins, the A9/A10 registers were configured to AF mode and UART AF, not analog.

salkinium · 2020-09-16T20:28:03Z

the A9/A10 registers were configured to AF mode and UART AF, not analog.

Of course, that makes sense, otherwise you'd need to have analog + AF mode, which isn't how this works.

I suggest the following: Let's add a public remap() function to the remappable pins, which set or clear the bit as you already coded. I find it much more confusing to automagically set this function in setOutput()/setInput()/configure(), especially with the weird G0 package problem.

chris-durand · 2020-09-16T20:32:48Z

I agree, with the G0 an automatic solution is very confusing and will not work. A public method called by the user is the only sensible way to go. Where would you add it? In the default pin class, the non-default or both? If it were in both and had a bool parameter, it is very confusing.

salkinium · 2020-09-16T20:36:12Z

Where would you add it? In the default pin class, the non-default or both?

I'd add it to only the pins occupying the same position (ie. A9/A11, A10/A12) and simply calling remap() sets this Gpio as remapped (ie. setting or clearing the right bit).

That way you'll get a "free" compiler error if you try it on a pin that cannot be remapped (same for AFs that don't exist on that pin).

chris-durand · 2020-09-16T20:41:28Z

OK, I'll do that.

chris-durand · 2020-09-16T21:26:49Z

@salkinium I think the L1 failing in CI are not caused by my changes.

salkinium · 2020-09-16T21:29:42Z

Looks like a CMSIS header issue, considering only the stm32l162zct6 is failing, but not it's sibling devices. I'll push some fixed on top of your branch without rebasing.

chris-durand · 2020-09-16T21:31:05Z

There are still some issues with some G0, for example stm32g071rbi

salkinium · 2020-09-16T22:27:04Z

Could you stop rebasing for a second here, I'm trying to fix something here…

chris-durand · 2020-09-16T22:29:43Z

Sorry, I was fighting against ST's inconsistent pin names across controller families, like for example: PB1/BOOT, PB1_BOOT, PB1-BOOT, PB1 BOOT, PB1 [BOOT]. I won't touch anything until you are done.

salkinium · 2020-09-16T22:30:48Z

I know, I've been there, the trick is to not fight against ST's pin naming ;-P

src/modm/platform/gpio/stm32/module.lb

salkinium · 2020-09-16T22:35:03Z

I think this code is equivalent to yours, but please double check.

salkinium · 2020-09-16T22:58:52Z

stm32l162zct6 is indeed failing because GPIOF and GPIOG are not defined in the CMSIS Header. This is because stm32l162zct6a is the variant that hase these pins.
So modm-devices has it wrong, it should not generate Port F/G pins on stm32l162xc devices only on stm32l162xc-a devices. Whyyyy, ST?

chris-durand

@salkinium Looks good

salkinium · 2020-09-16T23:02:26Z

Oh, there's another issue with modm-devices. Some STM32G0 devices have multiple GPIOs bonded to the same pin without any multiplexing:

      <package device-pin="y" name="WLCSP18">
        <pin position="A1" name="PA13"/>
        <pin position="A3" name="PA14-BOOT0"/>
        <pin position="A3" name="PA15"/>
        <pin position="A5" name="PB7"/>
        <pin position="A5" name="PB8"/>
        <pin position="A7" name="PC15-OSC32_OUT (PC15)"/>
        <pin position="B2" name="PA12 [PA10]"/>
        <pin position="B2" name="PA10 [PA12]" variant="remap"/>
        <pin position="B4" name="PB3"/>
        <pin position="B4" name="PB4"/>
        <pin position="B4" name="PB5"/>
        <pin position="B4" name="PB6"/>
        <pin position="B6" name="PC14-OSC32_IN (PC14)"/>
        <pin position="B6" name="PB9"/>
        <pin position="C1" name="PA11 [PA9]"/>
        <pin position="C1" name="PA9 [PA11]" variant="remap"/>
        <pin position="C3" name="PA5"/>
        <pin position="C5" name="PA1"/>
        <pin position="C7" name="VDD/VDDA" type="power"/>
        <pin position="D2" name="PA7"/>
        <pin position="D4" name="PA3"/>
        <pin position="D4" name="PA4"/>
        <pin position="D6" name="VSS/VSSA" type="power"/>
        <pin position="E1" name="PB0"/>
        <pin position="E1" name="PB1"/>
        <pin position="E1" name="PB2"/>
        <pin position="E1" name="PA8"/>
        <pin position="E3" name="PA6"/>
        <pin position="E5" name="PA2"/>
        <pin position="E7" name="PF2 - NRST"/>
        <pin position="E7" name="PA0"/>
      </package>

chris-durand · 2020-09-16T23:03:56Z

Oh no, ST, why?

src/modm/platform/gpio/stm32/module.lb

salkinium · 2020-09-17T01:37:17Z

The failure of the STM32L162QC and STML162ZC devices has its root problem in the selection of the appropriate define and thus CMSIS header file for the device.
They both do really have port F and port G, but the selected define and header file is wrong.

This is because modm tries to find the closest regular match, but the mapping is not regular.
Here the relevant part from the stm32l1xx.h header:

  /* #define STM32L162xC  */   /*!< STM32L162RC and STM32L162VC */
  /* #define STM32L162xCA */   /*!< STM32L162RC-A, STM32L162VC-A, STM32L162QC and STM32L162ZC */

  /* #define STM32L152xC  */   /*!< STM32L152CC, STM32L152UC, STM32L152RC and STM32L152VC */
  /* #define STM32L152xCA */   /*!< STM32L152RC-A, STM32L152VC-A, STM32L152QC and STM32L152ZC */

  /* #define STM32L151xC  */   /*!< STM32L151CC, STM32L151UC, STM32L151RC and STM32L151VC */
  /* #define STM32L151xCA */   /*!< STM32L151RC-A, STM32L151VC-A, STM32L151QC and STM32L151ZC */

You can see that ST assigns the QC and ZC devices the A-variant header. 🙄
I've thus fixed the define/header search to respect variants and special fix this for these devices.

chris-durand · 2020-09-17T09:13:00Z

The remap() method is still missing for F042F6 A9,A10 IOs, even when I update to the latest modm-devices. This means, you can set the the pins to the remapped setting but not back. For the G071RB they're all generated as expected.

salkinium · 2020-09-17T12:06:54Z

Ah, I didn't think about disabling this. The issues is in the raw data, which doesn't include the [PA9] part. Ugh… I was doing too many things at the same time yesterday.

 $ ack "PINREMAP" STM32F0*
STM32F042F4Px.xml
153:	<Pin Name="PA11" Position="17" Type="I/O" Variant="PINREMAP">
169:	<Pin Name="PA12" Position="18" Type="I/O" Variant="PINREMAP">

STM32F042F6Px.xml
153:	<Pin Name="PA11" Position="17" Type="I/O" Variant="PINREMAP">
169:	<Pin Name="PA12" Position="18" Type="I/O" Variant="PINREMAP">

STM32F042G(4-6)Ux.xml
163:	<Pin Name="PA11" Position="19" Type="I/O" Variant="PINREMAP">
180:	<Pin Name="PA12" Position="20" Type="I/O" Variant="PINREMAP">

STM32F048G6Ux.xml
152:	<Pin Name="PA11" Position="19" Type="I/O" Variant="PINREMAP">
168:	<Pin Name="PA12" Position="20" Type="I/O" Variant="PINREMAP">

STM32F070F6Px.xml
118:	<Pin Name="PA11" Position="17" Type="I/O" Variant="PINREMAP">
132:	<Pin Name="PA12" Position="18" Type="I/O" Variant="PINREMAP">

salkinium · 2020-09-17T12:10:50Z

Try this modm-devices fix, which adds the remap-default back in for STM32F0.

salkinium · 2020-09-17T12:27:44Z

Nonono, none of this works right.

salkinium · 2020-09-17T13:22:16Z

Nonono, none of this works right.

Now modm-devices using the right position information to find the remap pin pairs.

salkinium · 2020-09-17T13:54:14Z

The STM32G0 compile all fails because the multi-bonded pins can also be remapped!! Yay!1!!
(This is a bug, the other pins cannot be remapped).

      <package device-pin="j" name="SO8N">
        <pin position="1" name="PC14-OSC32_IN (PC14)"/>
        <pin position="1" name="PB7"/>
        <pin position="1" name="PB8"/>
        <pin position="1" name="PB9"/>
        <pin position="2" name="VDD/VDDA" type="power"/>
        <pin position="3" name="VSS/VSSA" type="power"/>
        <pin position="4" name="NRST" type="reset"/>
        <pin position="4" name="PA0"/>
        <pin position="4" name="PA1"/>
        <pin position="4" name="PA2"/>
        <pin position="5" name="PA9 [PA11]" variant="remap"/>
        <pin position="5" name="PB0" variant="remap-default"/>
        <pin position="5" name="PB1" variant="remap-default"/>
        <pin position="5" name="PA8" variant="remap-default"/>
        <pin position="5" name="PA11 [PA9]" variant="remap-default"/>
        <pin position="6" name="PA10 [PA12]" variant="remap"/>
        <pin position="6" name="PA12 [PA10]" variant="remap-default"/>
        <pin position="7" name="PA13"/>
        <pin position="8" name="PA14-BOOT0"/>
        <pin position="8" name="PA15"/>
        <pin position="8" name="PB5"/>
        <pin position="8" name="PB6"/>
      </package>

salkinium · 2020-09-17T14:55:32Z

Ok, I think I'm done with this now. I've checked that STM32G071 and STM32F042 now also generate the right A9 and A10 pins.

Can you check again? Then I'll squash and merge everything.

chris-durand · 2020-09-17T22:40:25Z

Looks good, go ahead!

Fixes STM32L1 define/header selection

chris-durand marked this pull request as draft September 16, 2020 18:09

salkinium mentioned this pull request Sep 16, 2020

[ext] Update modm-devices and stm32 submodules #470

Closed

2 tasks

chris-durand force-pushed the feature/stm32_remap_pins branch 2 times, most recently from 603bbee to abb3123 Compare September 16, 2020 20:58

chris-durand marked this pull request as ready for review September 16, 2020 20:58

chris-durand force-pushed the feature/stm32_remap_pins branch from abb3123 to d0972e2 Compare September 16, 2020 21:02

chris-durand changed the title ~~WIP: Support for STM32 F0/G0 remap pins~~ Support for STM32 F0/G0 remap pins Sep 16, 2020

salkinium added advanced 🤯 feature 🚧 labels Sep 16, 2020

chris-durand force-pushed the feature/stm32_remap_pins branch 2 times, most recently from 234af5e to b2cfa81 Compare September 16, 2020 22:24

salkinium reviewed Sep 16, 2020

View reviewed changes

src/modm/platform/gpio/stm32/module.lb Outdated Show resolved Hide resolved

chris-durand commented Sep 16, 2020

View reviewed changes

salkinium reviewed Sep 16, 2020

View reviewed changes

src/modm/platform/gpio/stm32/module.lb Outdated Show resolved Hide resolved

salkinium linked an issue Sep 17, 2020 that may be closed by this pull request

Remapped pins on STM32F0/G0 not supported #469

Closed

salkinium and others added 3 commits September 18, 2020 01:02

[ext] Update modm-devices submodule

31a2ced

[ext] Update STM32 CMSIS Headers

81265c6

Fixes STM32L1 define/header selection

[stm32] Add support for remapped A11/A12 pins on F0/G0

48d73dc

salkinium force-pushed the feature/stm32_remap_pins branch from 034f79f to 48d73dc Compare September 17, 2020 23:04

salkinium merged commit 48d73dc into modm-io:develop Sep 17, 2020

chris-durand deleted the feature/stm32_remap_pins branch September 17, 2020 23:41

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support for STM32 F0/G0 remap pins #471

Support for STM32 F0/G0 remap pins #471

chris-durand commented Sep 16, 2020

chris-durand commented Sep 16, 2020

salkinium commented Sep 16, 2020

chris-durand commented Sep 16, 2020

salkinium commented Sep 16, 2020

chris-durand commented Sep 16, 2020

salkinium commented Sep 16, 2020

chris-durand commented Sep 16, 2020

salkinium commented Sep 16, 2020

chris-durand commented Sep 16, 2020

salkinium commented Sep 16, 2020 •

edited

Loading

chris-durand commented Sep 16, 2020

chris-durand commented Sep 16, 2020

salkinium commented Sep 16, 2020

chris-durand commented Sep 16, 2020

salkinium commented Sep 16, 2020

chris-durand commented Sep 16, 2020 •

edited

Loading

salkinium commented Sep 16, 2020

salkinium commented Sep 16, 2020

salkinium commented Sep 16, 2020

chris-durand left a comment

salkinium commented Sep 16, 2020 •

edited

Loading

chris-durand commented Sep 16, 2020

salkinium commented Sep 17, 2020

chris-durand commented Sep 17, 2020

salkinium commented Sep 17, 2020 •

edited

Loading

salkinium commented Sep 17, 2020

salkinium commented Sep 17, 2020

salkinium commented Sep 17, 2020

salkinium commented Sep 17, 2020 •

edited

Loading

salkinium commented Sep 17, 2020 •

edited

Loading

chris-durand commented Sep 17, 2020

Support for STM32 F0/G0 remap pins #471

Support for STM32 F0/G0 remap pins #471

Conversation

chris-durand commented Sep 16, 2020

chris-durand commented Sep 16, 2020

salkinium commented Sep 16, 2020

chris-durand commented Sep 16, 2020

salkinium commented Sep 16, 2020

chris-durand commented Sep 16, 2020

salkinium commented Sep 16, 2020

chris-durand commented Sep 16, 2020

salkinium commented Sep 16, 2020

chris-durand commented Sep 16, 2020

salkinium commented Sep 16, 2020 • edited Loading

chris-durand commented Sep 16, 2020

chris-durand commented Sep 16, 2020

salkinium commented Sep 16, 2020

chris-durand commented Sep 16, 2020

salkinium commented Sep 16, 2020

chris-durand commented Sep 16, 2020 • edited Loading

salkinium commented Sep 16, 2020

salkinium commented Sep 16, 2020

salkinium commented Sep 16, 2020

chris-durand left a comment

Choose a reason for hiding this comment

salkinium commented Sep 16, 2020 • edited Loading

chris-durand commented Sep 16, 2020

salkinium commented Sep 17, 2020

chris-durand commented Sep 17, 2020

salkinium commented Sep 17, 2020 • edited Loading

salkinium commented Sep 17, 2020

salkinium commented Sep 17, 2020

salkinium commented Sep 17, 2020

salkinium commented Sep 17, 2020 • edited Loading

salkinium commented Sep 17, 2020 • edited Loading

chris-durand commented Sep 17, 2020

salkinium commented Sep 16, 2020 •

edited

Loading

chris-durand commented Sep 16, 2020 •

edited

Loading

salkinium commented Sep 16, 2020 •

edited

Loading

salkinium commented Sep 17, 2020 •

edited

Loading

salkinium commented Sep 17, 2020 •

edited

Loading

salkinium commented Sep 17, 2020 •

edited

Loading