Io mux

[ahepp]

Exposes the following bug in svdtools: https://github.com/stm32-rs/svdtools/issues/10, pull request submitted.

Basic description of IO_MUX registers. There are only two unique register layouts. Note that nothing has been done to reflect the restrictions on FUN_DRV, FUN_WPU, and FUN_WPD for GPIO34-39, other than setting their reset value to 0.

Relevant pages of TRM: 59, 70, 71

[MabezDev]

Hey thanks a lot for taking a stab at this. Unfortunately I wasn't as clear as I should have been; the idea with this crate is to apply patches to the generated svd, not modify the svd itself. We do this so that if we need to regenerate the svd from idf2svd then we can without losing manually applied patches such as this one.

To be a bit more explicit, I would:

• create a new yaml file inside svd/patches called io_mux.yaml.
• In there I would use the svdtools patching format to create the peripherals and its registers, see https://github.com/stm32-rs/svdtools#device-and-peripheral-yaml-format
• finally include that file inthe main svd/patches/esp32.yaml file

[ahepp]

That's a much better way of doing it. I hacked together a very poorly working script to translate from svd to patch, and got most of the data. I didn't carry over descriptions though (they were just the register name, so not a lot of value lost).

[ahepp]

I'm assuming the register reset values on pages 56 and 57 are correct, and the one on page 71 is not, so I'll fix that. I'd also like to add descriptions to registers and fields, and I'm assuming the name of the yaml file should be preceded with an underscore?

[ahepp]

I removed resetValues, since it wasn't clear to me what the spec meant on pages 56 and 57 (which enable and pull up/downs? FUN, MCU, both?).

[MabezDev]

Sorry for taking a while to get to this. Trying this locally, and I've ran into a snag:

error[E0599]: no method named `write` found for type `esp32::generic::Reg<u32, esp32::io_mux::_GPIO2>` in the current scope
  --> src/main.rs:86:18
   |
86 |     io_mux.gpio2.write(|w| unsafe { w.mcu_sel().bits(0b00) });
   |                  ^^^^^ method not found in `esp32::generic::Reg<u32, esp32::io_mux::_GPIO2>`
   |
   = note: the method `write` exists but the following trait bounds were not satisfied:
           `esp32::generic::Reg<u32, esp32::io_mux::_GPIO2> : esp32::generic::ResetValue`

I think we will need the reset values in, other than that this is looking great.

[ahepp]

Do you have thoughts about the TRM's statement on reset values? My assumption is that the reset configurations displayed in section 4.10, table 18, apply to only FUN_ fields.

[MabezDev]

Register 4.34 on page 71 shows the reset values for those registers. Inside the descriptions I found highlighted in red the exeptions:

• For GPIO34-39, FUN_DRV is always 0
• For GPIO34-39, FUN_WPU is always 0
• For GPIO34-39, FUN_WPD is always 0

Hope that helps.

[ahepp]

I suspect the reset value depicted in the register on page 71 is not representative of every register the diagram is supposed to stand in for, since page 57 seems to provide more detailed information about the reset states of various iomux pads.

[MabezDev]

You're right. I couldn't fully comprehend it from the datasheet so I just decided to inspect all the registers on reset with a gdb script.

0x3ff49004:     00000000000000000000100000000000
0x3ff49008:     00000000000000000000100000000000
0x3ff4900c:     00000000000000000000100000000000
0x3ff49010:     00000000000000000000100000000000
0x3ff49014:     00000000000000000000100000000000
0x3ff49018:     00000000000000000000100000000000
0x3ff4901c:     00000000000000000000100000000000
0x3ff49020:     00000000000000000000100000000000
0x3ff49024:     00000000000000000000100000000000
0x3ff49028:     00000000000000000000100000000000
0x3ff4902c:     00000000000000000000101000000000
0x3ff49030:     00000000000000000000101000000000
0x3ff49034:     00000000000000000000101010000000
0x3ff49038:     00000000000000000000101000000000
0x3ff4903c:     00000000000000000000101100000000
0x3ff49040:     00000000000000000000101010000000
0x3ff49044:     00000000000000000000101100000000
0x3ff49048:     00000000000000000000101010000000
0x3ff4904c:     00000000000000000000101000000000
0x3ff49050:     00000000000000000000101000000000
0x3ff49054:     00000000000000000000101100000000
0x3ff49058:     00000000000000000000101100000000
0x3ff4905c:     00000000000000000001101100000000
0x3ff49060:     00000000000000000001011100000000
0x3ff49064:     00000000000000000001101100000000
0x3ff49068:     00000000000000000001101100000000
0x3ff4906c:     00000000000000000000101100000000
0x3ff49070:     00000000000000000000101000000000
0x3ff49074:     00000000000000000000101000000000
0x3ff49078:     00000000000000000000101000000000
0x3ff4907c:     00000000000000000000101000000000
0x3ff49080:     00000000000000000000101000000000
0x3ff49084:     00000000000000000000101100000000
0x3ff49088:     00000000000000000000101000000000
0x3ff4908c:     00000000000000000000101000000000
0x3ff49090:     00000000000000000000100000000000

That should do it I think.

Edit: heres the list in hex, if thats easier:

0x3ff49004:     0x00000800
0x3ff49008:     0x00000800
0x3ff4900c:     0x00000800
0x3ff49010:     0x00000800
0x3ff49014:     0x00000800
0x3ff49018:     0x00000800
0x3ff4901c:     0x00000800
0x3ff49020:     0x00000800
0x3ff49024:     0x00000800
0x3ff49028:     0x00000800
0x3ff4902c:     0x00000a00
0x3ff49030:     0x00000a00
0x3ff49034:     0x00000a80
0x3ff49038:     0x00000a00
0x3ff4903c:     0x00000b00
0x3ff49040:     0x00000a80
0x3ff49044:     0x00000b00
0x3ff49048:     0x00000a80
0x3ff4904c:     0x00000a00
0x3ff49050:     0x00000a00
0x3ff49054:     0x00000b00
0x3ff49058:     0x00000b00
0x3ff4905c:     0x00001b00
0x3ff49060:     0x00001700
0x3ff49064:     0x00001b00
0x3ff49068:     0x00001b00
0x3ff4906c:     0x00000b00
0x3ff49070:     0x00000a00
0x3ff49074:     0x00000a00
0x3ff49078:     0x00000a00
0x3ff4907c:     0x00000a00
0x3ff49080:     0x00000a00
0x3ff49084:     0x00000b00
0x3ff49088:     0x00000a00
0x3ff4908c:     0x00000a00
0x3ff49090:     0x00000800

[MabezDev]

LGTM! I'm pretty sure we have everything we need to make an embedded_hal gpio driver for the esp32 now!