CFG File pinmux assignment changes in JP5 compared to JP4

Robotics & Edge Computing Jetson & Embedded Systems Jetson Xavier NX
1

Hi,

I have a question regarding the generation of the cfg files from the pinmux spreadsheet of the NX module for JetPack 5.

We have a custom board and updated the spreadsheet to support our hardware for JP4 and we are now migrating to JP5 and using the same spreadsheet.

After generating the cfg file using the JP5 scripts, I have noticed that bit 12 (E_SCHMT) of some of the pinmux values has now been set. Also, there was one pin that we assigned as tristate for JP4 that no longer works. If I change it to a “Drive 0” then it works.

A couple of questions:

  1. Why are these pins now assigned E_SCHMT for JP5 where they weren’t for JP4.
  2. How can the assignment of the E_SCHMT be changed/manipulated using the spreadsheet.
  3. I would like to know why the tristate assignment for a pin worked in JP4 and know no longer works in JP5. Is there a change in the JetPack 5 release that would prevent “some” pins from working properly in tristate?

Malcolm

2

A simple question to ask on top of MM’s above question: if the same xls spread sheet is being used as a source to generate the cfg file, then why the generated cfg file is different between JP4 and JP5? Is there some changes needed?

4

hello malcolm.mcdowell

may I know what’s your commands to convert dtsi files into cfg file.

here’s my commands,
python pinmux-dts2cfg.py --pinmux addr_info.txt gpio_addr_info.txt por_val.txt tegra19x-jetson_xavier_nx_module-pinmux.dtsi tegra19x-jetson_xavier_nx_module-gpio-default.dtsi 1.0 > xavier-nx_jp5.cfg

I cannot repo this issue.
I’ve create two cfg files under JP-4 and JP-5 for comparison, check the difference and they looks identical.

$ diff xavier-nx_jp4.cfg xavier-nx_jp5.cfg
5c5
< ## Generation date: 2022-10-05 11:12
---
> ## Generation date: 2022-10-05 11:11
5

Hi JerryChang,

That command that you provided is identical to the one that we are using.

However, there are some differences in the cfg file we generate. I would like to know what has caused or would cause the addition of E_SCHMT to be set as mentioned in questions #1 and #2 that I asked in the first post.

Malcolm

6

hello malcolm.mcdowell,

may I know which pin has assigned E_SCHMT.
please share the detail steps to reproduce this on our side. thanks

7

Hi JerryChang,

Here is one JP5 pin that has the bit set:
pinmux.0x0c302028 = 0x00001412; # spi2_mosi_pcc2: rsvd2, tristate-enable, input-disable, io_high_voltage-disable, lpdr-disable
versus JP4:
pinmux.0x0c302028 = 0x00000412; # spi2_mosi_pcc2: rsvd2, tristate-enable, input-disable, io_high_voltage-disable, lpdr-disable

This is the assignment in the excel spreadsheet:

image
image1522×44 4.62 KB

Let me know if you require more information.

Malcolm

8

hello malcolm.mcdowell,

interesting, the cfg file under JP-4 and JP-5 were identical to us.
could you please modify the register value manually and re-flash the target for confirmation.
thanks

9

Hi JerryChang,

If we edit the file and change the bit that was set, the target still works.

Is it possible to get the .dtsi files you used and allow us to run the conversion here?

Malcolm

10

hello malcolm.mcdowell,

you’re using flash script to perform full flash to update cfg file, right?
may I know your commands to update the pinmux configuration?

11

Hi JerryChang

I will provide a high level view of the process we follow.

  1. We use the excel spreadsheet to generate the dtsi files. They are copied to kernel/pinmux/t19x.

  2. Then the following command is run to generate the .cfg:
    python3 pinmux-dts2cfg.py
    –pad
    pad_info.txt
    tegra19x-jetson_xavier_nx_module-padvoltage-default.dtsi
    1.0
    > tegra19x-mb1-padvoltage-p3668-a01.cfg

  3. The generated .cfg files are copied to /bootloader/t186ref/BCT/

  4. The p3668.conf.common is verified to have the name of the new pinmux
    for PINMUX_CONFIG=“tegra19x-mb1-pinmux-p3668-a01.cfg”

  5. Then we use the flash.sh script to flash the device:
    sudo ./flash.sh jetson-xavier-nx-devkit-emmc mmcblk0p1

Thanks
Malcolm

13

hello malcolm.mcdowell

E_SCHMIT setting should follow PROD_SETTING, it’s por_val.txt for PROD_SETTING recommendations.
and… there’s change to update POR values, may I know which JetPack-4.x release you’re used for comparison, are you using the latest JetPack 4.6.2 release image?

moreover,
please check TRM for more details.
Enabling Schmitt provides better noise margin characteristics for the input and depending on driver’s logic threshold levels this can be enabled.

14

Hi JerryChang,

Thanks for the update on the POR change. We were using JetPack 4.6.1 before switching to JetPack5.

Malcolm

15

hello malcolm.mcdowell,

I’ve seen change also integrated to rel-32 code-line, you may moving to the latest JP-4 release for confirmation.

16

We are now using JetPack 5 now. As long as I understand the changes I am seeing. That is good.

Malcolm

17

hello malcolm.mcdowell,

thanks for confirmation. are we able to close this discussion thread?

18

Yes. Thanks for your help

20

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.