test/xtimer_hang: DEBUG_PINS #10174
test/xtimer_hang: DEBUG_PINS #10174
Conversation
|
@leandrolanzieri is this helpful? Mind to have a look? |
tests/xtimer_hang/main.c
Outdated
| @@ -38,14 +43,31 @@ char stack_timer2[TEST_TIMER_STACKSIZE]; | |||
|
|
|||
| void* timer_func(void* arg) | |||
| { | |||
| #ifdef WORKER_THREAD_PIN | |||
| printf("Debug worker thread port 0x%02x pin %d\n", WORKER_THREAD_PORT, WORKER_THREAD_PIN); | |||
| gpio_t worker_pin = GPIO_PIN(WORKER_THREAD_PORT, WORKER_THREAD_PIN); | |||
There was a problem hiding this comment.
There was a problem hiding this comment.
+1 on defining WORKER_THREAD_PIN and also MAIN_THREAD_PIN
|
I believe this is an interesting feature to have. @Josar maybe a note could be added on what to expect on the pins, like you did here #9211 (comment) ? |
|
@basilfx @leandrolanzieri done. |
|
@leandrolanzieri would you mind to ACK if you agree with this PR? Have you tested? |
|
Yes, I tested both with master and #9211, and observed the expected changes. So ACK. |
|
@leandrolanzieri tried to explain what is expected. So your ACK is for this PR. Are you also acknowledging #9211 ? |
|
Please squash and @leandrolanzieri please set the label for CI when it's squashed. |
tests/xtimer_hang/Makefile
Outdated
| @@ -6,4 +6,19 @@ USEMODULE += xtimer | |||
|
|
|||
| TEST_ON_CI_WHITELIST += all | |||
|
|
|||
| # Port and pin configuration for probing with oscilloscope | |||
| # Define Test pin for hardware timer interrupt, hardware dependent | |||
| # ATmega | |||
There was a problem hiding this comment.
which atmega exactly? or does this apply for all of them?
tests/xtimer_hang/Makefile
Outdated
| #FEATURES_REQUIRED += periph_gpio | ||
| # Jiminy probing Pins | ||
| #CFLAGS += -DWORKER_THREAD_PIN=GPIO_PIN\(PORT_F,7\) | ||
| #CFLAGS += -DMAIN_THREAD_PIN=GPIO_PIN\(PORT_F,6\) |
There was a problem hiding this comment.
as the gpio API is used here it may be better to suggest HW-independent port numbers like GPIO_PIN(5,7)
841dc87 to
c658ec6
Compare
|
Squashed and rebased. |
tests/xtimer_hang/README.md
Outdated
| This leads to a separation of the timer interrupts until they again fall in the same interrupt. | ||
| It might happen that from the seperation of the interrupts till the merge there is only a uneven count of | ||
| WORKER_THREAD_PIN toggles, which means a loss of one worker time 2, which is expected as it has a lower priority then | ||
| worker timer 1. And thus in the moment when the hardware interrupt for the 2 worker is executet it has to wait for the |
There was a problem hiding this comment.
Trailing whitespace here. Please remove.
Add the option to use debug pins to investigate timing issues.
c658ec6 to
162d17c
Compare
This PR adds debug pins to probe this test with an oscilloscope.
This helps debugging #9211
When runnig this on main branch it can be observed that the xtimer are not fired when they are expected. The whole system is interrupted for a whole timer circle untill the set target is reached again.
This is solved by #9211
What we wold expect is that the main pin is on for ca. 100ms and that in a regular interval
Also we would expect the worker to be after 1ms and 1.1ms. (As this falls in the XTIMER_ISR_BACKOFF the first timer is delayed untill the second is ready. Thus the time interval is longer.)
The second figure also shows cicled in red when there is a hardware interrupt before the second worker thread timer is set. This leads to a separation of the timer interrupts, As we only count 7 until they are in the same hardware interrupt again we lost one worker time 2, which is expected as it has a lower priority then worker timer 1. And thus in the moment when the hardware interrupt for the 2 worker is executet it has to wait for the 1 worker timer because of the XTIMER_ISR_BACKOFF and ten the first timer is executed first as it has the higher priority.