test/xtimer_hang: DEBUG_PINS#10174
Conversation
|
@leandrolanzieri is this helpful? Mind to have a look? |
tests/xtimer_hang/main.c
Outdated
| { | ||
| #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. |
MichelRottleuthner
left a comment
There was a problem hiding this comment.
Tested on arduino-mega2560 and z1 works as described. Just some minor things below - feel free to directly squash
tests/xtimer_hang/Makefile
Outdated
|
|
||
| # 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
leandrolanzieri
left a comment
There was a problem hiding this comment.
All looks good, tested and CI passing. ACK.
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.