TDA4VM: How to Interrupt route，The meaning of the "Sciclient_rmIrqSetRaw" parameter

Hi,

This API just configures GPIOMUX Interrupt router, so 

src_id and dst_id are same ie GPIOMUX Router ID, which TISCI_DEV_GPIOMUX_INTRTR0

src_index is GPIO Number, ie 93 in your case

dst_host_irq is the output irq allocated for mcu2_0. Please refer to the rm-cfg.c file to know which IRQs are allocated to mcu2_0 and then use the corresponding output id here. 

Regards,

Brijesh

Thank you, but I did not find this rm-cfg.c in the SDK 8.6 provided by the company,do you know what the reason may be

Hi,

You can find this file in PSDKLA\board-support\k3-image-gen-2022.01\soc\j721e\evm\rm-cfg.c.. 

According to this file, output 24 to 27 are allocated to mcu2_0 and 16 to 19 are allocated to mcu3_0.

{
.start_resource = 16,
.num_resource = 4,
.type = RESASG_UTYPE (J721E_DEV_GPIOMUX_INTRTR0,
RESASG_SUBTYPE_IR_OUTPUT),
.host_id = HOST_ID_MAIN_1_R5_0,
},

{
.start_resource = 24,
.num_resource = 4,
.type = RESASG_UTYPE (J721E_DEV_GPIOMUX_INTRTR0,
RESASG_SUBTYPE_IR_OUTPUT),
.host_id = HOST_ID_MAIN_0_R5_0,
},

If you require more than 4 interrupts, you need to allocate more IRQs on this core using sysconfig tool.

Regards,

Brijesh

I will communicate with my colleagues in the company to see if we can find it, Thank you.

Sure, i will move this ticket to waiting status. 

hi，I understand this part,if I only changed src_index, it should still run normally. However, in fact, if I only changed 90 to 93, the operation will still get stuck in the function "SemaphoreP_Pend", do you know what the possible reason is

Hi,

Is SciClient API executed successfully? Does it return success? Then GPIO number should not have mattered. If it is working for GPIO 90, it should work for GPIO 93. 

Can you check if corresponding bit is set in GPIO_INT_STAT for GPIO93? 

Regards,

Brijesh

90 can run normally. The configurations for 90 and 93 are the same, but I just changed 90 to 93 and the program won't run anymore

The return values for 90, 93, and SciClient API are both correct

ok, can you first check if the corresponding bit is set and GPIO_INT_STAT indicates that GPIO interrupt is generated? If the interrupt itself is not generated, there will not be frame completion interrupt.

Yes, I printed the GPIO_INTSTAT register and changed the IO to 93. GPIO_INTSTAT has always been 0, but the two IO configurations are the same. Why is this happening

Hi tao liu,

That's strange. GPIO_INTSTAT must be set in both the cases in order for the interrupt to be generated. If this is not set, can you please first check why this is not getting set? 

Regards,

Brijesh

I didn't find out why the register GPIO_INTSTAT of 93 was not set to 1, but I changed the IO to 77, and the GPIO_INTSTAT was normally set to 1, but the phenomenon is the same as before.

Hi,

Pinmux could be one reason why INTSTAT is not set to 1 for GPIO93. So can you please check pinmux? Also please check if the corresponding bank interrupt is enabled for GPIO93.

Regards,

Brijesh

Hi,

Okay, thank you. Let me check if there are any issues with Pinmux; After changing the IO that can trigger interrupts, the program still stuck as before. Do you think it may be related to anything else.

Regards,

tao liu

Hi tao liu,

Program will get stuck because there is no interrupt from the GPIO, so first lets confirm that GPIO is generating interrupt, which should be indicated in GPIO_INTSTAT register.

Regards,

Brijesh