Hello Team,
Hello Tushar,
As per your suggestion, we have identified the below APIs to configure and set the debounce time as per the document. Please check the below API flow and let us know if anything is missing. If any corrections are needed in the below details and API details, please let me know.
======================================================================================================
/* MCU_PADCONFIG16 (MCU_GPIO0_16) Physical Address is 0x04084040 (MCU_PADCFG_CTRL0_CFG0_PADCONFIG16) */
readDinDataValue = HW_RD_REG32(0x4084040);
/* Configure MCU_CTRL_MMR_DBOUNCE_CFG1 register in the
* MCU_PADCFG_CTRL0_CFG0_PADCONFIG16 for MCU_GPIO0_16.
* The MCU_CTRL_MMR_DBOUNCE_CFG1 register contains the
* debounce period for pads with PADCONFIGx [13–11] DEBOUNCE_SEL fields set to 1h.*/
configureDebounceRegValue = readDinDataValue | 0x800;
HW_WR_REG32(0x4084040, configureDebounceRegValue);
/*Set the Debounce-Period value in MCU_CTRL_MMR_DBOUNCE_CFG1 (0x04504084) registers for */
/* 2 means debounce period in 2.93 milliseconds */
HW_WR_REG32(0x04504084, 2);
======================================================================================================
We used the physical address to read and write registers using the HW_RD_REG32() and HW_WR_REG32() APIs.
Is it the correct method or not? Please provide confirmation on it.
Thanks,
Nisarg
Hi Tushar,
We tried below code to configure the debounce of 10-millisecond for the MCU_GPIO0_16 (MCU_PADCONFIG16 with Physical-Address is 0x04084040)
and tried to generated continues input-interrupt on that pin (MCU_GPIO0_16 ) using 1KHz Input Signal (with 50% duty cycle) (Use functional Generator to generate input signal) but observed that ISR not generated for every 10-millisecond but getting ISR after 457-millisecond which is not correct as per the debounce-time settings.
1KHz = 1 millisecond duration
Code Snippet:-
/*Set Debounce-Time for DIN Pin */
uint8_t setDINDebounceTime(uint8_t time)
{
uint8_t retValue = SUCCESS;
uint32_t configureDebounceRegValue = 0;
uint32_t readDinDataValue = 0;
/* MCU_PADCONFIG16 (MCU_GPIO0_16) Physical Address is 0x04084040 */
readDinDataValue = HW_RD_REG32(DIN_PHY_ADDRESS);
/* Configure MCU_CTRL_MMR_DBOUNCE_CFG1 register in the
* MCU_PADCFG_CTRL0_CFG0_PADCONFIG16 for MCU_GPIO0_16.
* The MCU_CTRL_MMR_DBOUNCE_CFG1 register contains the
* debounce period for pads with PADCONFIGx[13-11] DEBOUNCE_SEL fields set to 1h.*/
configureDebounceRegValue = readDinDataValue | 0x800;
HW_WR_REG32(DIN_PHY_ADDRESS, configureDebounceRegValue);
/*Set Debounce-Period value in MCU_CTRL_MMR_DBOUNCE_CFG1 (0x04504084) registers for */
HW_WR_REG32(MCU_CTRL_MMR_DBOUNCE_CFG1_PHY_ADDR, time); /* time means Debounce-Period in mili-second*/
return retValue;
}
In ISR, Toggling one TEST-GPIO and captured below test-result using CRO on that TEST-GPIO.
Adding extra prints in above API code, to check below register values before setting debounce-time and after setting debounce-time (10 milliseconds debounce time)
/* MCU_GPIO0_16 (MCU_PADCONFIG16) */
#define DIN_PHY_ADDRESS 0x04084040
/* MCU_CTRL_MMR_DBOUNCE_CFG1 PHY Address */
#define MCU_CTRL_MMR_DBOUNCE_CFG1_PHY_ADDR 0x04504084
Thanks
Nisarg
Hello Nisarg,
1) How do we set/change the frequency of the GPIO?
2) How do we check the current operating frequency of GPIO?
Please refer to the Clock tree tool for AM62A device for clock related information and visualization. Please refer Clock Tree.
Please refer below screenshot.
Regards,
Tushar
Hello Tushar,
We checked as per your provided link and we found the below thing for MCU_GPIO0
But our question is: how do we configure/change the MCU_GPIO0 frequency using CCS Tool with the "example.syscfg" file?
We checked MCU_GPIO0 current clock-related information on board using "k3conf" command
Commands:-
k3conf show device | grep "MCU_GPIO"
k3conf dump clock 79
k3conf dump parent_clock 79 0
How do we configure/change the MCU_GPIO0 frequency using CCS Tool with the "example.syscfg" file? Or provide commands/APIs to configure the required frequency for debounce support in MCU_GPIO0???
Thanks,
Nisarg
Hello Anil,
Please check our below-mentioned old response. We don't want to change the GPIO-Frequency. We want to configure debounce on GPIO. We have tried to set debounce on GPIO, but we are not getting the expected result on debounce. Please check below for the details.
Hi Tushar,
We tried below code to configure the debounce of 10-millisecond for the MCU_GPIO0_16 (MCU_PADCONFIG16 with Physical-Address is 0x04084040)
and tried to generated continues input-interrupt on that pin (MCU_GPIO0_16 ) using 1KHz Input Signal (with 50% duty cycle) (Use functional Generator to generate input signal) but observed that ISR not generated for every 10-millisecond but getting ISR after 457-millisecond which is not correct as per the debounce-time settings.
1KHz = 1 millisecond duration
Code Snippet:-
Fullscreen12345678910111213141516171819202122/*Set Debounce-Time for DIN Pin */uint8_t setDINDebounceTime(uint8_t time){uint8_t retValue = SUCCESS;uint32_t configureDebounceRegValue = 0;uint32_t readDinDataValue = 0;/* MCU_PADCONFIG16 (MCU_GPIO0_16) Physical Address is 0x04084040 */readDinDataValue = HW_RD_REG32(DIN_PHY_ADDRESS);/* Configure MCU_CTRL_MMR_DBOUNCE_CFG1 register in the* MCU_PADCFG_CTRL0_CFG0_PADCONFIG16 for MCU_GPIO0_16.* The MCU_CTRL_MMR_DBOUNCE_CFG1 register contains the* debounce period for pads with PADCONFIGx[13-11] DEBOUNCE_SEL fields set to 1h.*/configureDebounceRegValue = readDinDataValue | 0x800;HW_WR_REG32(DIN_PHY_ADDRESS, configureDebounceRegValue);/*Set Debounce-Period value in MCU_CTRL_MMR_DBOUNCE_CFG1 (0x04504084) registers for */HW_WR_REG32(MCU_CTRL_MMR_DBOUNCE_CFG1_PHY_ADDR, time); /* time means Debounce-Period in mili-second*/In ISR, Toggling one TEST-GPIO and captured below test-result using CRO on that TEST-GPIO.
Adding extra prints in above API code, to check below register values before setting debounce-time and after setting debounce-time (10 milliseconds debounce time)
/* MCU_GPIO0_16 (MCU_PADCONFIG16) */
#define DIN_PHY_ADDRESS 0x04084040/* MCU_CTRL_MMR_DBOUNCE_CFG1 PHY Address */
#define MCU_CTRL_MMR_DBOUNCE_CFG1_PHY_ADDR 0x04504084
Kindly help us on the above issue why debounce time not working as per the setting values? Please check the above API and details and let us know if we need to add additional settings or not. We are waiting for your response.Thanks
Nisarg
Thanks,
Nisarg
Hello Anil,
Please provide clarity on the below queries.
I internally checked with Paul and confirmed that clock selection of GPIO IP and debounce clock selection are not the same.
Kindly provide more details on above information.
i) What is the clock section of GPIO-IP?
i) What is the debounce clock selection?
iii) How is this clock selection related to 32.768 KHz and 25 MHz GPIO-Case?
iv) What is the difference between 32.768KHz and 25MHz GPIO-Case?
As per the above table, you have configured the DEBOUNCE CONFIG VALUE is 10, you can keep as tease and don't change GPIO IP clock selection. configure GPIO interrupt type is both rising edge and falling edge type.
Does the 10 (DEBOUNCE CONFIG VALUE is 10) value work for the 25MHz GPIO-Case or not? Please provide more details on it.
So, please provide test results at 10Hz, 5Hz, 3.3Hz, 2.5Hz and 2HZ signal to GPIO rather than the 1KHz signal and don't change the debounce period.
For the above input signals, the frequency-to-time table is below. What will be the duty cycle for the below input signal?
10Hz -> 100ms (milliseconds)
5Hz -> 200ms (milliseconds)
3.3Hz -> 303.03 ms (milliseconds)
2.5Hz -> 400ms (milliseconds)
2Hz -> 500ms (milliseconds)
In that case, how does the 10 (DEBOUNCE CONFIG VALUE is 10) value in debounce work for the 10Hz (100 milliseconds) input signal for 25 MHz GPIO-Case? Please provide more information on this.
Our last question is, Did you check debounce configuration value-10 (DEBOUNCE CONFIG VALUE is 10) for the 1KHz (1 milliseconds) input signal for 25MHz GPIO-Case or not?
Thanks,
NIsarg
Hello Anil,
As per your request, we have captured the result for the 10Hz, 5Hz, and 2Hz input signals to GPIO (Interrupt Generation with 50% Duty Cycle) and configured the DEBOUNCE CONFIG VALUE 10 during that testing.
i) Yellow Color Signal is Input Signal (GPIO-Input Interrupt) (1st Waveform in Screenshot)
ii) The neon-pink color signal represents an O/P toggle GPIO signal from ISR (2nd Waveform in screenshot)
1) 10Hz Input-Signal with debounce-decimal value is 10 configured
2) 5Hz input signal with debounce-decimal value is 10 configured
3) 2Hz input signal with debounce-decimal value is 10 configured
Interrupt ISR Logic
void DINTriggerISR(void *args)
{
BaseType_t xHigherPriorityTaskWoken = pdFALSE;
uint32_t statusRegister = 0;
xTaskNotifyIndexedFromISR(TaskP_getHndl(&triggerDINTaskObj),
0,
statusRegister,
eNoAction,
&xHigherPriorityTaskWoken);
#if 1 /*-TESTING ONLY-*/
if (getGpioValue(MCU_GPIO_DIN_PIN))
{
setGpioValue(MCU_GPIO_CAM_TRIGGER_PIN, GPIO_PIN_HIGH);
}
else
{
setGpioValue(MCU_GPIO_CAM_TRIGGER_PIN, GPIO_PIN_LOW);
}
#endif
portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}
In all the above results, we have observed that we have configured the debounce value 10 (10.74 milliseconds), but we are getting a delay of 14 milliseconds b/w input signal detection to GPIO toggle from ISR. We have configured the interrupt on both rising and falling edges.
Why are we getting 14-millisecond delay b/w two signal when debounce configured 10? Is it expected behavior? Please provide more information on it.
Let's assume SOC detects first high signal after the 10msec and next 10msec , again SOC detects high signal and not detects low ..
SOC detects the same high signal till 455msec . Due to this Ton period is approximately ~455msec
At some point after 455msec , SOC detects the low signal till 922msec .So, you are getting total 922msec Time period
Kindly provide more clarity on which base SoC detects the above 1KHz input signal when the debounce value is configured as 10. How does it detect a 455 millisecond Ton period? Need more information on this.
Thanks,
Nisarg
In all the above results, we have observed that we have configured the debounce value 10 (10.74 milliseconds), but we are getting a delay of 14 milliseconds b/w input signal detection to GPIO toggle from ISR. We have configured the interrupt on both rising and falling edges.
Why are we getting 14-millisecond delay b/w two signal when debounce configured 10? Is it expected behavior? Please provide more information on it.
Hello Nisarg,
Here there are different problems because of the debounce period that does not match with the actual input.
I am not sure about your Test setup, and it seems to include many peripheral/Applications in your Test setup.
If you included many peripherals in your Test setup, there might be a chance the interrupts are disabled during critical sections and once this critical section is done, the interrupts resumes.
Due to this delay, your GPIO interrupt gets delayed, and one more thing is that you are measuring time with the GPIO, hence we need to include GPIO latency time as well.
I recommend removing all applications except your test application and toggle GPIO directly write in to the Registers in NORTOS examples .
Based on the above results, we can confirm, still you have the same results as the above or not.
If you still have the above results, then there is a problem with the debounce table.
Based on the above results, we need to configure the debounce period to be always less than the input frequency.
Kindly provide more clarity on which base SoC detects the above 1KHz input signal when the debounce value is configured as 10. How does it detect a 455 millisecond Ton period? Need more information on this.
Issue Analysis points :
The 1msec signal is given to GPIO and configured the debounce period is 10msec.
SOC detects/captures the signal after 10msec only.
You can see in the above table, SOC detects 0 at 0th msec even though the signal is high because the debounce period is 10msec.
Exactly at 10msec, SOC detects high.
Next, the input signal is change from low to high and high to low for the 10 times in next 10msec.
Exactly at 20msec again, SOC detects the same high signal.
Next, the input signal is change from low to high and high to low for the 10 times in next 10msec.
Exactly after 30msec again, SOC detects the same high signal and so on ...
There are no GPIO transitions occurring in above Test case.
Due to this, the GPIO interrupt is not triggered.
At some point, the GPIO detects low that time you are getting an interrupt and SOC is detecting low signal might be at the 455msec.
The same behavior for low signal as well and finally you are getting 922msec period due to above behavior .
Actually, you have configured a 10msec debounce period and given a 1msec signal to the GPIO .
This is not a valid test case for validating debounce periods.
To test the debounce periods properly, the feeding signal time period should be longer as compared to the debounce period.
Regards,
Anil.
Hello Nisarg,
Here there are different problems because of the debounce period that does not match with the actual input.
I am not sure about your Test setup, and it seems to include many peripheral/Applications in your Test setup.
If you included many peripherals in your Test setup, there might be a chance the interrupts are disabled during critical sections and once this critical section is done, the interrupts resumes.
Due to this delay, your GPIO interrupt gets delayed, and one more thing is that you are measuring time with the GPIO, hence we need to include GPIO latency time as well.
I recommend removing all applications except your test application and toggle GPIO directly write in to the Registers in NORTOS examples .
Based on the above results, we can confirm, still you have the same results as the above or not.
If you still have the above results, then there is a problem with the debounce table.
Hello Anil,
Thanks for these details, but we have checked the same code setup with the no-debounce configuration, and we found no latency b/w input signal detection to GPIO toggle from ISR. (Application running on MCU-R5 FreeRTOS)
1) 10Hz input signal and no-debounce configuration on GPIO-Input Interrupt PIN.
2) 5Hz input signal and no-debounce configuration on GPIO-Input Interrupt PIN.
3) 2Hz input signal and no-debounce configuration on GPIO-Input Interrupt PIN.
Please check the above details and let us know if we still need to change the test setup or not.
Thanks,
Nisarg
Hi Anil,
During our last testing, we captured the below different debounce time results with 10Hz Input signal.
1) 10Hz input signal with debounce-decimal value is 15 configured (15.63 ms)
2) 10Hz input signal with debounce-decimal value is 21 configured (21.48 ms)
Please check the above different debounce time results with a 10Hz input signal.
Please let us know if you need more details on it. We are waiting for your response.
Thanks,
Nisarg
Hello Nisarg,
Based on the above results, I suspect that there might be problem with the a debounce table.
Your test setup is OK.
One more note that all pins mux modes do not support debounce functionality.
Please look at the latest datasheet for more details about which pins support this functionality.
I can check with Paul internally and will come back.
Regards,
Anil.
Hello, Anil,
Thanks for your response !!!
Thanks for the the above information.
Internally discussed with Hw experts and they confirmed that there is might be problem with the debounce validation Testing.
So, instead of giving frequency signals, we need to send pulse width which a needs to be changed, and please look at Paul comments.
Please try with Paul suggestion and share test results and do the same testing at 10, 15 and 21 debounce configures.
Kindly provide more details above points. The frequency signal also contains a definite pulse width of ON and OFF periods based on the duty cycle. Kindly provide more clarity on the above point. We will check/test accordingly and collect the data.
We have already checked input frequency signals with different debounce values and already shared results with you. We are waiting for your response.
Hi Anil,
During our last testing, we captured the below different debounce time results with 10Hz Input signal.
1) 10Hz input signal with debounce-decimal value is 15 configured (15.63 ms)
2) 10Hz input signal with debounce-decimal value is 21 configured (21.48 ms)
Please check the above different debounce time results with a 10Hz input signal.
Please let us know if you need more details on it. We are waiting for your response.
Thanks,
Nisarg
Thanks,
Nisarg
Hi Paul,
Hello Anil,
Thanks for these details, but we have checked the same code setup with the no-debounce configuration, and we found no latency b/w input signal detection to GPIO toggle from ISR. (Application running on MCU-R5 FreeRTOS)
1) 10Hz input signal and no-debounce configuration on GPIO-Input Interrupt PIN.
2) 5Hz input signal and no-debounce configuration on GPIO-Input Interrupt PIN.
3) 2Hz input signal and no-debounce configuration on GPIO-Input Interrupt PIN.
Please check the above details and let us know if we still need to change the test setup or not.
Thanks,
Hi Anil,
During our last testing, we captured the below different debounce time results with 10Hz Input signal.
1) 10Hz input signal with debounce-decimal value is 15 configured (15.63 ms)
2) 10Hz input signal with debounce-decimal value is 21 configured (21.48 ms)
Please check the above different debounce time results with a 10Hz input signal.
Please let us know if you need more details on it. We are waiting for your response.
Thanks,
Nisarg
We have previously checked input frequency signals with different debounce values and shared results (CRO captured results) with TI-Team in this forum. Please check above old data results. From above results we can see that variation between expected and actual debounce results.
Does above information is not sufficient to identify this issue ? Please let us know if you need more details on it. We are waiting for your response.
We need to communicate the root cause of this issue with the customer. So please provide the root cause, whether this is a hardware defect or our configuration is incorrect. If this is a hardware defect, then please provide the correct table information, which is supported by the MCU processor currently.
Thanks,
Nisarg