RIOT
RIOT copied to clipboard
boards/waspmote-pro: add sdcard configuration
Contribution description
Add the SD card configuration to the waspmote-pro board.
Testing procedure
Before this change:
$ PORT=/dev/ttyUSB0 BOARD=waspmote-pro make -C tests/driver_sdcard_spi all flash term
> init
2022-08-12 11:24:53,190 # init
2022-08-12 11:24:53,446 # Initializing SD-card at SPI_0...[FAILED]
2022-08-12 11:24:53,494 # enable debugging in sdcard_spi.c for more information!
> size
2022-08-12 11:24:56,837 # size
2022-08-12 11:24:56,838 #
2022-08-12 11:24:56,853 # Card size:
2022-08-12 11:24:56,885 # 4 bytes (0,000 GiB | 0,000 GB)
After this change:
$ PORT=/dev/ttyUSB0 BOARD=waspmote-pro make -C tests/driver_sdcard_spi all flash term
> init
2022-08-12 11:26:32,527 # init
2022-08-12 11:26:32,686 # Initializing SD-card at SPI_0...[OK]
> size
2022-08-12 11:26:34,110 # size
2022-08-12 11:26:34,111 #
2022-08-12 11:26:34,127 # Card size:
2022-08-12 11:26:34,158 # 2008023040 bytes (1,870 GiB | 2,008 GB)
Issues/PRs references
none
Thank you! Want to also provide a MTD configuration and a default mount point? You can just copy this file and add
ifneq (,$(filter mtd,$(USEMODULE)))
USEMODULE += mtd_sdcard
endif
# default to using fatfs on SD card
ifneq (,$(filter vfs_default,$(USEMODULE)))
USEMODULE += fatfs_vfs
USEMODULE += mtd
endif
to the board's Makefile.dep
tests/mtd_raw and tests/vfs_default should then work.
Now tests/mtd_raw works:
$ BOARD=waspmote-pro PORT=/dev/ttyUSB0 make -C tests/mtd_raw all flash term
[...]
2022-08-12 13:35:11,968 # main(): This is RIOT! (Version: 2022.10-devel-291-g4edab1-waspmote-sdcard)
2022-08-12 13:35:11,984 # Manual MTD test
2022-08-12 13:35:12,145 # init MTD_0… OK (1915 MiB)
> info
2022-08-12 13:35:17,631 # info
2022-08-12 13:35:17,647 # mtd devices: 1
2022-08-12 13:35:17,663 # -=[ MTD_0 ]=-
2022-08-12 13:35:17,679 # sectors: 3921920
2022-08-12 13:35:17,695 # pages per sector: 1
2022-08-12 13:35:17,711 # page size: 512
2022-08-12 13:35:17,727 # total: 1915 MiB
But tests/vfs_default does not:
BOARD=waspmote-pro PORT=/dev/ttyUSB0 make -C tests/vfs_default all flash term
[...]
2022-08-12 13:51:18,714 # main(): This is RIOT! (Version: 2022.10-devel-293-g8782e-waspmote-sdcard)
2022-08-12 13:51:18,730 # mount points:
2022-08-12 13:51:18,730 #
2022-08-12 13:51:18,746 # data dir: /sd0
> ls /sd0
2022-08-12 13:51:52,706 # ls /sd0
2022-08-12 13:51:52,723 # vfs_opendir error: -ENOENT
> ls /
2022-08-12 13:51:54,082 # ls /
2022-08-12 13:51:54,114 # vfs_opendir error: -ENOENT
I've tried examples/filesystem with 2 different cards, one formatted with fatfs and the other with littlefs2.
Both work with the feather-m0 board, but both fail to mount with the waspmote-pro.
Does the test command in tests/mtd_raw work?
No:
> test 0
2022-08-12 14:11:06,955 # test 0
2022-08-12 14:11:06,971 # [START]
2022-08-12 14:11:07,003 # tests/mtd_raw/main.c:404 => failed condition
2022-08-12 14:11:07,035 # *** RIOT kernel panic:
2022-08-12 14:11:07,051 # CONDITION FAILED.
2022-08-12 14:11:07,051 #
2022-08-12 14:11:07,067 # *** halted.
2022-08-12 14:11:07,067 #
Does tweaking SD_CARD_SPI_SPEED_POSTINIT make a difference?
Does tweaking
SD_CARD_SPI_SPEED_POSTINITmake a difference?
Tried the different options, from 100KHZ to 10MHZ, no change, same error.
Verified the waspmote libs https://github.com/Libelium/waspmoteapi/ and they use the same configuration as in SPI_CLK_10MHZ (SPI2X=1 SPR1=0 SPR0=0)
Can you set ENABLE_DEBUG in sdcard_spi/sdcard_spi.c to see what's going wrong?
Hmm maybe the SD card driver has still bugs on AVR - I'll try to reproduce this on my arduino-mega2560 if RAM permits.
In the meantime, looks like KConfig needs an update too.
I do have a theory why there are issues on AVR:
2022-09-09 15:54:00,969 # data dir: /sd0
> vfs ls /sd0
2022-09-09 15:54:19,403 # vfs ls /sd0
2022-09-09 15:54:19,433 # OVERLAYS/
2022-09-09 15:54:19,451 # CONFIG~1 194179 B
2022-09-09 15:54:19,471 # INITRA~1 5238543 B
2022-09-09 15:54:19,490 # FIXUP4.DAT 5354 B
2022-09-09 15:54:19,512 # START4.ELF 2240608 B
2022-09-09 15:54:19,532 # START.ELF 2964864 B
2022-09-09 15:54:19,550 # CMDLINE.TXT 58 B
2022-09-09 15:54:19,610 # BOOTCODE.BIN 52460 B
2022-09-09 15:54:19,656 # scheduler(): stack overflow detected, pid=0
However, it is not the idle thread that overflowed, but the main thread that overflowed all the way into the idle thread. With this, it works a bit better:
diff --git a/cpu/atmega_common/include/cpu_conf.h b/cpu/atmega_common/include/cpu_conf.h
index 44031b54b8..eb83fc15f1 100644
--- a/cpu/atmega_common/include/cpu_conf.h
+++ b/cpu/atmega_common/include/cpu_conf.h
@@ -42,7 +42,11 @@ extern "C" {
* @{
*/
#ifndef THREAD_STACKSIZE_DEFAULT
-#define THREAD_STACKSIZE_DEFAULT (512)
+#define THREAD_STACKSIZE_DEFAULT (512)
+#endif
+
+#ifndef THREAD_STACKSIZE_MAIN
+#define THREAD_STACKSIZE_MAIN (1024)
#endif
/* keep THREAD_STACKSIZE_IDLE > THREAD_EXTRA_STACKSIZE_PRINTF
@@ -55,9 +59,9 @@ extern "C" {
* trivial stuff is needed to be done in ISRs (e.g. when soft timers are used),
* the idle stack will overflow.
*/
-#define THREAD_STACKSIZE_IDLE (192)
+#define THREAD_STACKSIZE_IDLE (192)
#else
-#define THREAD_STACKSIZE_IDLE (128)
+#define THREAD_STACKSIZE_IDLE (128)
#endif
#endif
/** @} */
~
2022-09-09 16:06:39,176 # main(): This is RIOT! (Version: 2022.10-devel-597-gded960-sys/tiny_strerror)
2022-09-09 16:06:39,190 # mount points:
2022-09-09 16:06:39,196 # /sd0
2022-09-09 16:06:39,197 #
2022-09-09 16:06:39,213 # data dir: /sd0
vfs ls /sd0
2022-09-09 16:06:41,040 # vfs ls /sd0
2022-09-09 16:06:41,077 # FIXUP.DAT 7314 B
2022-09-09 16:06:41,095 # FIXUP4.DAT 5448 B
2022-09-09 16:06:41,119 # SYSTEM~1.MAP 4328313 B
2022-09-09 16:06:41,141 # START4.ELF 2228800 B
2022-09-09 16:06:41,160 # CONFIG~1 207723 B
2022-09-09 16:06:41,181 # VMLINU~1 19730944 B
2022-09-09 16:06:41,241 # START.ELF 2952960 B
2022-09-09 16:06:41,395 # ALPINE~1 25 B
2022-09-09 16:06:41,524 # OVERLAYS/
2022-09-09 16:06:41,654 # DTBS-R~1/
2022-09-09 16:06:41,793 # INITRA~1 4162721 B
2022-09-09 16:06:41,934 # BCM271~1.DTB 26894 B
2022-09-09 16:06:42,096 # BCM271~2.DTB 29011 B
2022-09-09 16:06:42,338 # BCM271~3.DTB 28392 B
2022-09-09 16:06:42,555 # CONFIG.TXT 378 B
2022-09-09 16:06:42,777 # BOOTCODE.BIN 52456 B
2022-09-09 16:06:42,999 # BCM271~4.DTB 26890 B
2022-09-09 16:06:43,221 # BCM271~5.DTB 49218 B
2022-09-09 16:06:43,463 # BCM283~1.DTB 20120 B
2022-09-09 16:06:43,587 # vfs_readdir error: -EIO
vfs df
2022-09-09 16:06:54,704 # vfs df
2022-09-09 16:06:54,771 # Mountpoint Total Used Available Use%
2022-09-09 16:06:54,839 # /sd0 1146 MiB 1078235 KiB 95269 KiB 0%
But still, I didn't had that error on an STM32. So there still seems to be something not fully 8 bit safe.
@jdavid Could you test tests/vfs_default again in combination with https://github.com/RIOT-OS/RIOT/pull/18572 ?
Since PR #18572 has been merged, I rebased, but I still get the same behaviour.
Who can one obtain the hardware? If it is not too expensive, I would like to buy one so that I can reproduce the issue.
I've updated Kconfig.
Who can one obtain the hardware? If it is not too expensive, I would like to buy one so that I can reproduce the issue.
Don't know where to buy one, but maybe @ArcticSnow knows.
@maribu, you can purchase one directly fromLibelium. They do not have online store anymore, and you need to contact them directly. Otherwise, I can send you a board for for the time of debugging.
Just wondering: Have you tried a different SD card? 2 GiB is quite small, might use some different code path than more recent (larger) SD cards.
I think I may have a 2 GB card somewhere. I relatively sure I do have a < 4 GB card at home. Maybe I can reproduce the issue with my hardware at home.
Please squash!
I've squashed to 2 commits, one for the sdcard and another for mtd. Or should I squash to only 1 commit?
@leandrolanzieri any idea why KConfig is still failing?
@leandrolanzieri any idea why KConfig is still failing?
the added dependencies for the board are not reflected in Kconfig. Although it is not ideal IMO, one could handle it like so for now: https://github.com/RIOT-OS/RIOT/blob/3f8f6e929d9da2015d292d50b7a9284589aaacf1/boards/waveshare-nrf52840-eval-kit/Kconfig#L27-L29
Thank you! What's weird is that neither sensebox_samd21 nor esp32-wrover-kit have this.
All green :tada:
Please squash!
Since this is a single commit, we can do the squashing in Github directly