PROCESSOR-SDK-AM62X: The GPIO appears problem when exporting pin and writing value.

正常情况、导出gpio后reboot后情况、导出gpio后电源关闭再打开情况
root@ok6254:~# echo 330 > /sys/class/gpio/export 
[   66.668165] wangguan export_store
[   66.668183] wangguan gpio_to_desc
[   66.671502] wangguan gpio 330
[   66.674877] wangguan gdev->base:314    gdev->base + gdev->ngpio:402 
[   66.677864] wangguan return normal
[   66.684210] wangguan desc->gdev->chip
[   66.687624] wangguan status1 :0
[   66.691276] wangguan status1 :0
[   66.694622] wangguan status1 :0


root@ok6254:~# cat /sys/kernel/debug/gpio 
gpiochip2: GPIOs 314-401, parent: platform/601000.gpio, 601000.gpio:
 gpio-330 (                    |sysfs               ) in  lo 
 gpio-336 (                    |fixed-regulator-rgb ) out lo 

gpiochip1: GPIOs 402-488, parent: platform/600000.gpio, 600000.gpio:
 gpio-433 (                    |net-5g-rst          ) out lo ACTIVE LOW
 gpio-437 (                    |phy_rstn            ) out lo 
 gpio-438 (                    |id                  ) in  lo 
 gpio-440 (                    |RT9186              ) out lo 
 gpio-441 (                    |fixed-regulator-lvds) out lo 
 gpio-442 (                    |phy_rstn            ) out lo 
 gpio-473 (                    |regulator-6         ) out lo 

gpiochip0: GPIOs 489-511, parent: platform/4201000.gpio, 4201000.gpio:


导出gpio后按下复位按键情况
root@ok6254:~# echo 330 > /sys/class/gpio/export 
[   40.124132] wangguan export_store
[   40.124150] wangguan gpio_to_desc
[   40.127480] wangguan gpio 330
[   40.130830] wangguan gdev->base:337    gdev->base + gdev->ngpio:425 
[   40.133787] wangguan gdev->base:425    gdev->base + gdev->ngpio:512 
[   40.140159] wangguan return null
[   40.146506] wangguan !desc
[   40.149738] export_store: invalid wangguan GPIO 330
-sh: echo: write error: Invalid argument
root@ok6254:~# cat /sys/kernel/debug/gpio 
gpiochip1: GPIOs 337-424, parent: platform/601000.gpio, 601000.gpio:
 gpio-359 (                    |fixed-regulator-rgb ) out lo 

gpiochip0: GPIOs 425-511, parent: platform/600000.gpio, 600000.gpio:
 gpio-456 (                    |net-5g-rst          ) out lo ACTIVE LOW
 gpio-460 (                    |phy_rstn            ) out lo 
 gpio-461 (                    |id                  ) in  lo 
 gpio-463 (                    |RT9186              ) out lo 
 gpio-464 (                    |fixed-regulator-lvds) out lo 
 gpio-465 (                    |phy_rstn            ) out lo 
 gpio-496 (                    |regulator-6         ) out lo 
root@ok6254:~# 

After button resetting,the base value of gpio is changed.

Our resetting circuit:

Hi Susan,

the console log you provided shows the MCU_GPIO0 doesn't exist after "reset", which makes the base pin number of MAIN_GPIO1 (which the LED pin 330 belongs to) changed from 314 to 337. That is why pin 330 is no longer valid after "reset".

Basically you shouldn't use a fixed GPIO number (330 in this case), instead, you need to query the chipset base pin number, and plus the offset to get the GPIO number you are going to use.

Hi Bin，

Thanks for your response.

The customer's understanding is that although the reset of the A core does not affect the M core, due to the failure of the MCU_GPIO to reset normally, the gpio chip number of the A core has changed, which affects the use of the A core itself.

Customer would like to know will this situation be avoided?

Thanks,

Annie

Hi Annie,

Is power-cycle the board an option?

Yes, customer has tried power-cycle. After power-cycle, the gpiochip number is normal. And there is no problem with the A core and the M core being reset together.
This startup process is normal: Start the A core --> initialize the device tree to allocate the pins of the A core and the M core --> M core startup call. Because the reset button resets the A core, if push the button of reset at this time, it will cause the use of the M core to be abnormal.  Even affects the gpiochip number of the A core. This makes it seem that the A core is also has problem.

Hi Susan,

What you described is expected. If the reset button connects to MAIN domain warm reset or MAIN domain POR, it only resets the MAIN domain, the MCU GPIO module doesn't get reset.

In this case, MCU GPIO is used by the A core, so the MCU domain should be reset while the MAIN domain resets, the reset button should connect to MCU RESETz or MCU PORz pin, so it can trigger both MAIN domain and MCU domain reset.

But TI advertised that this CPU can support the M core to run independently, and now the premise of the M core running independently is that the pins of the M core cannot be initialized in the device tree of the A core. But if it is not initialized, these functions of the M core cannot be used normally. So this is the contradictory.