[FAQ] TDA4: How to validate SysConfig PinMux Tool outputs

Finding PADCONFIG registers and bitfields

Within a device datasheet, the Pin Attributes table will contain PADCONFIG register names and addresses. For example, TDA4VH datasheet contains this information in column 2 of its Pin Attributes table.

The PADCONFIG bitfield definitions can be found in the respective device’s TRM registers. For example, PADCONFIG_51 at address 0x0011C0CC.

Please note the CTRL_MMR regions from the Memory Maps section in the TRM.

Validating devicetree.dtsi

The devicetree.dtsi is used in the SDK environment.

A typical output will look like this:

There are three fields within the J784S4_IOPAD parentheses. Let’s use line 9 as an example. This correlates to PADCONFIG_51 in TDA4VH datasheet. The MAIN domain’s PADCONFIG base address is defined as 0x0011C000.

• 0x0cc – Field 1 is the offset from the base address defined for this PADCONFIG region
• PIN_INPUT – Field 2 correlates to RXACTIVE bitfield (bit 18) in the PADCONFIG register
• 7 – Field 3 correlates to MUXMODE bitfield (bits 3:0) in the PADCONFIG register

The GUI has configurable options which will adjust the SysConfig PinMux Tool output.

These Field 2 options affect the following bitfields in the PADCONFIG register:

• PIN_INPUT – affects RXACTIVE (bit 18 set) and PULLUPEN (bit 16)
• PIN_INPUT_PULLUP – affects RXACTIVE (bit 18 set), PULLUPEN (bit 16), and PULLTYPESEL (bit 17)
• PIN_INPUT_PULLDOWN – affects RXACTIVE (bit 18 set), PULLUPEN (bit 16), and PULLTYPESEL (bit 17)
• PIN_OUTPUT – affects RXACTIVE (bit 18 clear) and PULLUPEN (bit 16)
• PIN_OUTPUT_PULLUP – affects RXACTIVE (bit 18 clear), PULLUPEN (bit 16), and PULLTYPESEL (bit 17)
• PIN_OUTPUT_PULLDOWN – affects RXACTIVE (bit 18 clear), PULLUPEN (bit 16), and PULLTYPESEL (bit 17)

TXDIS (bit 21) is always clear.

The Linux SDK may define multiple PADCONFIG regions for the MAIN domain or WKUP domain. For more information, please refer to this thread: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1285219/tda4vh-q1-pinmux-mcu_adc0-out-of-range/

Validating <device>_pinmux.h

The <device>_pinmux.h is used in baremetal code.

A typical output will look like this:

This header file defines the register offsets similar to the devicetree.dtsi file. The MAIN domain’s PADCONFIG region base address is 0x0011C000. The header file also contains defines which detail the bitfields within the PADCONFIG register. This is used to configure the PADCONFIG register in the corresponding source file.

Validating <device>_pinmux_data.c

The <device>_pinmux_data.c is used in baremetal code.

A typical output will look like this:

This source file will configure each pin using the defines from the header file generated by the tool. Let’s look at lines 32-33 as an example.

• PIN_SPI0_CS0 – This define is the enumeration defined in the header file. It correlates to the register offset
• PIN_MODE(7) – This define correlates to MUXMODE bitfield (bits 3:0) in the PADCONFIG register
• PIN_PULL_DISABLE – This define correlates to PULLUDEN bitfield (bit 16) in the PADCONFIG register
• PIN_INPUT_ENABLE – This define correlates to RXACTIVE bitfield (bit 18) in the PADCONFIG register
• PIN_PULL_DIRECTION – This define correlates to the PULLTYPESEL bitfield (bit 17) in the PADCONFIG register

Please ensure the final PADCONFIG configuration is reflected in your program by dumping the register and checking the register value against the PinMux Tool output.