Sync with TUD and update to feather board #5
Conversation
|
Currently I am experiencing an issue with my feather board running |
|
Just for the record, the commits are taken from https://github.com/netd-tud/WSN-exercises |
Can confirm this locally: "This is a timers example" is still printed but everything afterwards (blinking led, reporting timeout) doesn't happen. |
|
Unfortunately I will be available only on Tuesday to look into it. Can we try to offload this task to someone who is not busy? (or who is busy but also knowledgeable @MichelRottleuthner ) |
|
Hmm I tried hard but I could not reproduce the timer hang - not even a single time. I tried with up-to date docker build and also with my local arm-none-eabi-gcc 13.2.0. Adafruit mentions here:
We have a few rev. B (black PCB) and now many new rev. C (blue PCB). Unfortunately the accel/gyro sensor was swapped for a different model, which may require further extensions to the lsm6dsxx driver (similar to RIOT-OS/RIOT#20170). Rev. C is the one that gets stuck with 04-saul. @mguetschow which board revision do you guys have at TUD? |
|
Thanks a lot for looking into this @MichelRottleuthner !
We have black PCBs and I can find a B inside a circle on the lower-left corner of the back side. I guess that means we have rev. B boards, or how else could I find it out? |
That was a very good hint, I can confirm that it doesn't crash with |
|
Interestingly enough, I also don't encounter the problem on the oldstable Raspberry Pi OS with arm-none-eabi-gcc 8.3.1. |
Yes that's exactly how I checked it. The circled letter next to the D2 pin indeed gives you the revision. Perfect. so you have a large amount of rev.B and we have a large amount of rev.C 🤦 😅 |
Could you elaborate what this was/is about? We just encountered an issue with So turns out gcc in Docker is actually older than my local one, and we should probably investigate these problems further for the future. |
Although @MichelRottleuthner's For |
We didn't investigate the warm/cold start issue back then as we only got it rarely and was easy to workaround at the time we saw it. The observed symptoms just looked exactly as the behavior as you described. Unfortunately I don't know what caused it and I don't get it on my system.
I used the last commit of this PR (aa8d5d9) without any changes, so no accelerometer code added. But I also think the addition won't make a difference as it will likely already fail during autoinit. |
|
I also think we make need one of these interactive sync module additions since we always seem to lose the initial output due to the "high_level_stdio" with pyterm... # Since we are using a high_level_stdio, we may loose the initial output
# from the board. To avoid this, we can use the interactive sync module
# that allows us to tell the application to run
USEMODULE += test_utils_interactive_sync
|
|
Working on task 08 with a current diff of: diff --git a/08-coap-basic/client.c b/08-coap-basic/client.c
index 06902bb..a6e67ba 100644
--- a/08-coap-basic/client.c
+++ b/08-coap-basic/client.c
@@ -109,7 +109,7 @@ static size_t _send(uint8_t *buf, size_t len, char *addr_str, char *port_str)
return 0;
}
- bytes_sent = gcoap_req_send(buf, len, &remote, _resp_handler, NULL);
+ bytes_sent = gcoap_req_send(buf, len, &remote, _resp_handler, NULL, GCOAP_SOCKET_TYPE_UNDEF);
if (bytes_sent > 0) {
req_count++;
}
diff --git a/RIOT b/RIOT
index 833571f..a9b9569 160000
--- a/RIOT
+++ b/RIOT
@@ -1 +1 @@
-Subproject commit 833571f630d8770e1cb216d4f77a75500e945902
+Subproject commit a9b956932d7af293bb0530cff462e447edcf88cd |
Only finished task 1 here but seems ok...
There were some gcoap api changes and the most important thing is the generic feather-nrf52840-sense board useage so we dont need to worry about which rev
|
So just about fully tested, we need some workarounds and probably can fix the root causes later... |
This syncs with all the non-TUD specific changes (ie, anything that isn't 00-*) and updates the target board to the
feather-nrf52840-sense,