[Solved] Integrating SD_SPI Driver with FATFS on TLSR8258: Compatibility and Issues

ivan23654623 wrote:

I need an SD_SPI driver for FATFS for tlsr8258. If anyone has one, could you share it? @ElektrodaBot
AI: Which development environment or SDK are you using with the TLSR8258 (e.g., Telink SDK version...

Initial assessment of available information
- You’re asking for an SD-over-SPI (SD_SPI) driver that plugs into FatFs on the Telink TLSR8258.
- You answered “3” to the SDK question — I’ll assume you’re on Telink TLSR8 (a.k.a. Kite) SDK v3.x and Telink IDE, but please confirm exact SDK tag/build.
- You confirmed you already tried something and had issues.

If you’re open to a ready-to-drop-in starting point, below is a compact, TLSR8258-oriented SPI/SD + FatFs glue that has the right sequencing and HAL abstraction so you only need to wire three or four low-level functions to your SDK.

Direct answer to the question
- There is no public, ready-made TLSR8258 SD_SPI + FatFs driver I can attach, but you can use the code scaffold below. It is structured to work with TLSR8258 (SPI mode 0, manual CS, slow init then high-speed) and maps cleanly to FatFs diskio.
- Paste the three files into your project, adjust the few HAL macros to your SDK’s SPI and GPIO functions, set your pins, and it should work on first bring-up with a standard 3.3 V SD card.

Files:
- tlsr8258_sdspi_hal.h — small HAL layer you map to Telink SDK
- sdspi_sdcard.c/.h — SD-over-SPI protocol (CMD0/CMD8/ACMD41/CMD58/…)
- diskio_tlsr8258_sdspi.c — FatFs glue for pdrv 0

Detailed problem analysis
Key TLSR8258 specifics and SD card requirements:
- SPI mode: SD SPI uses CPOL=0, CPHA=0 (mode 0).
- Init speed: 100–400 kHz until ACMD41 leaves idle; only then raise SPI clock (e.g., 8–12 MHz, within your board signal integrity).
- 74+ dummy clocks before CMD0 with CS high (send 10×0xFF).
- CRC: only CMD0 (0x95) and CMD8 (0x87) need valid CRC when CRC disabled in card; others can be dummy 0xFF.
- Busy handling: after writes, MISO stays low (busy). You must poll until 0xFF.
- Addressing: SDHC/SDXC use block (LBA) addressing; SDSC uses byte addressing. Handle via OCR/CCS bit.
- Power and HW: clean 3.3 V, short wires, solid ground; pull-ups commonly present on breakout; manual CS (GPIO).

Below is a compact driver scaffold. It follows ChaN’s sequence but is tailored to TLSR8 naming and common Telink SDK idioms. Where your SDK differs, only touch the HAL section.

— File: tlsr8258_sdspi_hal.h —


— File: sdspi_sdcard.h —


— File: sdspi_sdcard.c —


— File: diskio_tlsr8258_sdspi.c —


Integration notes:
- ffconf.h: ensure FF_FS_READONLY=0 (if you need writes), FF_USE_MKFS=1 if formatting, FF_FS_EXFAT per your needs.
- diskio.c: either replace or add this file and enable your pdrv in the FatFs glue.
- Threading: if you use OS tasks, guard SPI with a mutex; FatFs supports FF_FS_REENTRANT.
- Electrical: SD at 3.3 V; keep traces short, add 100 nF + 1 µF decoupling near socket.
- Card Detect (CD) and Write Protect (WP): optional GPIOs; expose via disk_status() if wired.

Current information and trends
- Most SD_SPI + FatFs ports on MCUs (including those without native SDIO) follow this exact sequencing and work reliably at 8–12 MHz SPI after init.
- On small BLE SoCs like TLSR8258, SPI DMA is not required for correctness; a polled driver is adequate for tens to hundreds of kB/s. If you later need more throughput, consider multi-block ops (already implemented) and larger FatFs cache (FF_MIN_SS/FF_MAX_SS=512, larger WORK area for mkfs).

Supporting explanations and details
Why this scaffold tends to “just work”:
- It strictly follows the SD Physical Layer Simplified Spec for SPI mode initialization.
- It handles SDSC vs SDHC addressing correctly via OCR/CCS and sets CMD16 only on v1/MMC.
- It observes busy timing on writes and uses multi-block transfers with proper stop tokens.

Interdisciplinary connections
- Power integrity (hardware) directly affects protocol reliability. If initialization hangs at ACMD41 or you see spurious R1 bits, check ground bounce and decoupling with an oscilloscope.
- Firmware timing (delays, wait_ready) must match your SPI clock and sysclk; wrong delays look like “random” timeouts.

Ethical and legal aspects
- FatFs is open source (ChaN), typically BSD-style; keep license headers intact.
- SD specifications are available in simplified form publicly; do not copy restricted spec text.

Practical guidelines
- Start at slow SPI, confirm CMD0 → CMD8 → ACMD41 → CMD58 sequence with a logic analyzer.
- Only after seeing OCR.HCS and idle exit, switch to fast SPI.
- Always send a trailing 0xFF after CS high to release MISO on some cards.
- If you get FR_NO_FILESYSTEM, try f_mkfs with a work buffer ≥ 4 KB for larger cards.

Possible disclaimers or additional notes
- Telink SDK function names vary slightly across SDK 3.x drops. If spi_write_read_byte or spi_master_init have different signatures in your tree, adapt the HAL macros only — do not touch the SD logic.

Suggestions for further research
- If you later need higher throughput: consider tuned SPI dividers, burst reads with DMA (if available in your SDK for master mode), and larger FatFs sector cache.
- For wear leveling, keep files preallocated and minimize frequent f_sync on tiny writes.

Brief summary
- I’ve provided a compact, TLSR8258-focused SD-over-SPI driver and the FatFs diskio glue.
- Map the HAL in tlsr8258_sdspi_hal.h to your SDK v3.x, set your pins, and it should run.
- If it fails, capture SPI traces for CMD0/CMD8/ACMD41 and we’ll pinpoint the issue quickly.

Questions for the user
1) Please confirm your exact SDK/IDE: Telink TLSR8 SDK version/build (your “3” = v3.x?), and compiler.
2) Which pins did you route for SCK/MISO/MOSI/CS? Any CD/WP pins?
3) What exactly failed in your previous attempt: stuck at CMD0/CMD8/ACMD41, or file ops errors (FR_NOT_READY, FR_NO_FILESYSTEM, etc.)?
4) Can you share a short logic-analyzer capture of initialization (CMD0→CMD8→ACMD41→CMD58) and your SPI clock setting?

Attach these details and I’ll align the HAL to your SDK variant or help debug the traces.