[kvdb] Support 256bit write granularity for kvdb

[Baseline-K]

• Support 256bit write granularity
  The new stm32h7xx chips can only write double quad words, i.e. 256bits.

*Update fdb_tsdb.c to include 256bit option
*Update fdb_cfg.h to include 256it option.

[Copilot]

Pull request overview

Adds 256-bit flash write granularity support for KVDB to accommodate STM32H7 devices that require 256-bit (double quadword) programming, and updates related configuration/documentation and TSDB compile-time guards.

Changes:

• Allow FDB_WRITE_GRAN == 256 in KVDB configuration checks.
• Add 256-bit-specific alignment padding in KVDB sector/KV header structs.
• Update TSDB compile-time error guard and the config template comment to mention 256-bit granularity.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
src/fdb_tsdb.c	Extends TSDB’s compile-time unsupported-granularity check to include 256-bit.
src/fdb_kvdb.c	Allows 256-bit granularity and adjusts header struct padding for alignment.
inc/fdb_cfg_template.h	Documents 256-bit write granularity option for STM32H7 in the template config.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The TSDB compile-time error string could be made clearer/grammatically correct (e.g. "Flash write granularities 64/128/256 bits are not supported in TSDB yet"). This helps users quickly understand which configurations are invalid.

Suggested change

	#error "Flash 64 or 128 or 256 bits write granularity is not supported in TSDB yet!"
	#error "Flash write granularities 64/128/256 bits are not supported in TSDB yet."

[armink]

@Baseline-K Because the mainline has undergone some updates, including the addition of the _fdb_flash_write_align function, some conflicts have arisen. Could you handle them?

[Baseline-K]

Merge conflicts have been resolved. Please review the changes, Thanks.

[Baseline-K]

I ran the 256-bit KVDB and TSDB read/write tests on an H743VIT6 board. Tests passed. I've attached my test code and the terminal output logs.[

FlashDB_Test.zip

](url)

[armink]

Sorry, there are some conflicts again. Could you please rebase it if it's convenient for you? Also, could you add a test case with 256-write granularity here?

[Baseline-K]

Thanks — I’ll rebase this branch onto main, resolve the conflicts (paying special attention to _fdb_flash_write_align), and add a 256-bit entry to the CI matrix.

[Baseline-K]

I have merged the latest changes from the mainline into my branch and added 256-bit write granularity to the CI tests. Please take a look~.

[armink]

The message indicates there's still a conflict.

[Baseline-K]

Sorry for the delay. With the help of AI, I have identified the root cause of the CI test failure. The details are as follows: [TEST_TS_COUNT was a fixed value (256) that did not account for FDB_WRITE_GRAN. With FDB_WRITE_GRAN=256, each TSL occupies significantly more space due to larger status tables and alignment padding, causing the ring buffer to wrap around before all 256 records could be stored. The fix computes TEST_TS_COUNT dynamically from the actual per-sector capacity (similar to how TEST_ITER1_COUNT was already handled), ensuring the test passes regardless of write granularity.]. 
The CI test code has been updated accordingly and verified locally. Please take another look.

[armink]

Sorry for the delay. With the help of AI, I have identified the root cause of the CI test failure. The details are as follows: [TEST_TS_COUNT was a fixed value (256) that did not account for FDB_WRITE_GRAN. With FDB_WRITE_GRAN=256, each TSL occupies significantly more space due to larger status tables and alignment padding, causing the ring buffer to wrap around before all 256 records could be stored. The fix computes TEST_TS_COUNT dynamically from the actual per-sector capacity (similar to how TEST_ITER1_COUNT was already handled), ensuring the test passes regardless of write granularity.]. 
The CI test code has been updated accordingly and verified locally. Please take another look.

Wow, CI is indeed passed, but there are still conflicts ;>

[Baseline-K]

The rebase is done and conflicts have been resolved. The branch is now cleanly mergeable. I sincerely apologize for repeatedly submitting due to my lack of experience. Please take a look，Thanks!

[armink]

Thank you for your contribution, the PR has been merged! 🎉