Are you able to post a schematic of your board? Nothing should change in the firmware from board to board.
Things are very simple. An external interrupt directly attached to GPIO:P3. Nothing fancy.
I am wondering if you know if there any specific functions that could reset/erase my interrupt setup. We are still looking on this
because in theory it should just work.
I am also using the UART and I am wondering if there could be a conflict.
1 of 1 people found this helpful
Unfortunately, there is no way to un-register an interrupt.
Once an interrupt is registered, the only control the application thread has over it is the configuration of the GPIO.
1 of 1 people found this helpful
I set the pin configuration using the BLE_PROFILE_GPIO_CFG. I enable the interrupt and set it high. In the _create() function I do the same as the example in How to Register for an Interrupt, Project 2 Wrap-Up and here GPIO usage in WICED Smart SDK.
Then I monitor the value of the pin using gpio_getPinInput() and inside the create function I get a value of 1. I can even see that the interrupt is fired right after the initialization, but when I am still inside the create function.
Once the create() function is done, I evaluate the pin value in the timer, and there I see that the pin value goes to zero. After that, it remains there, and no interrupts are captured. My guess is that the GPIO is being reset somewhere but I don't know where. What is executed right after create()? Advertising? I am not sure right now, but once it gets to the timer the GPIO value is zero.
I have a question regarding the usage of the gpio_configurePin(). In my case I am using the (TEST _PIN >> 4) and the (TEST _PIN & 0x0f). So the question is, should I set the TEST_PIN to 3 (as the GPIO:P3 that I am using) or set it to 30 (which is the actual pin on the chip).
Thank you for your help
Polling an input and waiting for an interrupt are two different things.
Calling gpio_getPinInput() will not show you the status of the interrupt. The numbers you get when polling this function are irrelevant because the pin is not configured as an input.
The best way to know if you have triggered an interrupt is to register for a callback and do something in that callback.
Do not use physical pin numbers, use the GPIO numbers as you have been.
Please review my post on interrupts: How to Register for an Interrupt, Project 2 Wrap-Up. There is attached code at the bottom that you can load onto your board, just match the pin numbers to test the interrupt.
Here is my initialization code.
#define GPIO_PIN_SENS_INT 03
#define GPIO_SETTINGS_SENS_INT (GPIO_INPUT | GPIO_INIT_HIGH | GPIO_INT)
Then inside the create() function I do the following:
gpio_registerForInterrupt(interrupt_handler_mask, my_interrupt_handler, NULL);
GPIO_INTERRUPT_ENABLE | GPIO_INPUT_ENABLE | GPIO_EN_INT_RISING_EDGE,
I run this code using the Tag3 board and my interrupt fires correctly and everything is fine.
I do the same in our circuit and the interrupt will not fire. Therefore, I started monitoring the GPIO pin.
It starts high in both cases but the difference is that in our board something pulls the pin low right after the create function.
I can see the interrupt fire a couple of times and then stay low. I am not sure why this is happening.
The difference is that puart is receiving and sending data in our board. The puart initialization code is working and I am
making sure that hardware flow is off and everything is almost identical to puart_control example (GPIO:P3 is PUART_CTS).
I am wondering if my etrx callback is doing something there, when I clear the interrupt and enable the interrupt.
Specifically these two commands:
P_UART_INT_ENABLE |= P_UART_ISR_RX_AFF_MASK;
Any insight is welcome.
If you turn off all PUART communication (never initialize), does the interrupt begin to work?
No, unfortunately not. I have disabled several parts of the code without any effect.
Right, when the create function starts, I am getting two numbers on the traces that I am not sure of their origin, but they
are different between the Tag3 and our board. Certainly they do not come from a ble_trace and they are coming internally. I am wondering what they might represent. Do you have any ideas?
I am comparing the output from the Tag3 and our board and everything else is the same up to the end of the create function.
Given that you're attempting the same firmware on two different boards--one works and the other doesn't--the only difference in the firmware could be producing is in pin configuration. Assuming you have different pins hooked up to the interrupt from board to board, please attempt to interrupt from different pins on your board. This is the only possible solution in the firmware if you have otherwise left the code identical. Other than this it must be a hardware issue.
Thank you for your reply. We just checked the board and the interrupt is firing correctly. There is a mismatch in the values that
we get from probing and the value that the get_pinInput is giving. We are thinking that there must be a mismatch in the pins.
So we are using the BCM20737S Bluetooth Low Energy System-in-Package (SiP) Module and the difference is that P3 is in pin 30 in this module but is Pin 21 in the Tag3 board. Unfortunately we cannot change the pin at this point.
Could the Puart_CTS interfering with the pin? How can I make sure that the pin is not used by something else like the PUART?
At this point, we are running out of ideas and any help would be appreciated.
To clarify, you did get the interrupt to properly trigger the callback on a different pin than the one you've been using?
We can't test a different GPIO at this point.
My start up procedure includes the following calls that I can't verify that they are not messing with my settings,
I know that I am registering the interrupt correctly because the interrupt is fired twice after the initialization.
After that the line remains low (based on the gpio_getInput). On the other hand the oscilloscope indicates that
the line is high and I can see the interrupt firing, which means that either I am looking at the wrong pin
or someone else is touching the configuration of that pin.
One last question, related to the pin numbers. How do I know that I am using the right configuration (GPIO:P3 is pin 30 and not pin 21)
except from the fact that everything else is working just fine?
I want to check that I am using the right file with the right definitions. Where should I look?