Add proper Zephyr module support with updated HAL for v3/v4 compatibility

[tbitcs]

Summary

This PR introduces first-class support for integrating CryptoAuthLib as a Zephyr module, compatible with Zephyr v3 and v4. It enables seamless integration into modern Zephyr-based applications using CMake and Kconfig, and updates the I2C and SPI HALs to align with Zephyr's evolving include path conventions.

Note: This change breaks compatibility with Zephyr v2.x due to header path and module resolution changes.

---

Key Changes

• Added module.yml to enable Zephyr module recognition via west.
• Introduced ATCA_ZEPHYR_SUPPORT CMake option to toggle Zephyr build mode.
• Created zephyr_options.cmake to map CONFIG_ATCA_* Kconfig options to internal CMake flags.
• Refactored HAL sources (I2C, SPI) to use updated Zephyr include paths (zephyr/drivers/...) required in Zephyr ≥ v3.
• Updated top-level CMakeLists to:
• Detect Zephyr toolchain
• Build as a zephyr_library() when enabled
• Export include paths and config headers for Zephyr apps

---

Integration Instructions

To include CryptoAuthLib as a Zephyr module:

Option 1: In-tree

Place CryptoAuthLib under modules/lib/cryptoauthlib and it will be automatically detected.

Option 2: Out-of-tree

If using a separate path:

# Add this line before find_package(Zephyr)
set(EXTRA_ZEPHYR_MODULES ${CMAKE_CURRENT_SOURCE_DIR}/../modules/lib/cryptoauthlib)

---

Kconfig Support

Once integrated, you can configure CryptoAuthLib via prj.conf using new symbols:

CONFIG_ATCA_HAL_I2C=y
CONFIG_ATCA_CRYPTO_MBEDTLS=y
CONFIG_ATCA_DEVICE_SUPPORT_ECC608=y

These options automatically propagate to the CMake build system, enabling or disabling relevant sources and flags.

---

Compatibility Notes

• Verified working on Zephyr v3.5 and v4.1.0
• Breaks backward compatibility with Zephyr v2.x
• No functional changes for non-Zephyr builds (Linux/MPLAB/Harmony remain unaffected)

---

Request

If possible, please test against MPLAB Harmony and existing Linux builds to ensure continued compatibility. Feedback and improvements welcome!

Feature branch: https://github.com/BitConcepts/cryptoauthlib/tree/feature/zephyr-module-support-v3-v4

[ElectroInnovator]

Follow-Up Update: I2C Send Function Refactored for Zephyr HAL

This follow-up commit introduces a significant improvement to the I2C HAL layer for Zephyr:

Summary

Refactors hal_i2c_send in hal_zephyr_i2c.c to support word-address-based I2C transfers and improve compatibility with Zephyr's I2C API.

Key Changes

• Updated function signature: uses word_address instead of address for semantic clarity.

• Reads device address from ATCAIfaceCfg, supporting both atcai2c->slave_address and cfg->dev_addr for backward compatibility.

• Implements a two-message I2C transfer:

  • First message transmits the word address.
  • Second (optional) message transmits the data buffer, if data is provided.

• Uses i2c_transfer() instead of i2c_write() for explicit control over transaction flags.

• Sets appropriate I2C flags:

  • I2C_MSG_WRITE
  • I2C_MSG_STOP only after the final message

• Adds parameter validation for both the Zephyr I2C device and the provided config structure.

Motivation

Many I2C peripherals require a separate word address phase before sending data. This update ensures broader device compatibility and aligns our I2C send logic with Zephyr HAL best practices.

Impact

• Increases robustness and configurability of I2C transactions.
• No API change for external callers of hal_i2c_send(), aside from the renamed argument.
• Improves support for devices with word-addressed registers (e.g., EEPROMs, secure elements).

[github-actions]

This PR has been marked as stale and will be automatically closed in 7 days.

[github-actions]

This PR has been marked as stale and will be automatically closed in 7 days.

[tbitcs]

Just checking in on the status of PR #407. I understand things can get busy, but I wanted to keep this from going stale. If there are any updates or concerns, please let me know how I can assist to help move this forward. Thank you!

[Srinivas-E]

Hi @tbitcs ,
We are planning this PR for review and merge at our next CAL release (mostly on v3.8.0 slotted for ~ Mar release - for your note and info.

[github-actions]

This PR has been marked as stale and will be automatically closed in 7 days.

[tbitcs]

Commenting to keep this PR from going stale.

[tbitcs]

Update: Bug fixes, platform verification, and Zephyr test suite

This latest push fixes several bugs found during a full review, aligns the Zephyr pieces with Zephyr style/guidelines, and adds a Zephyr build-verification test suite.

Bug fixes

1. hal_i2c_send() and ATCA_STRICT_C99
   The Zephyr I2C HAL was directly accessing cfg->atcai2c.address instead of using ATCA_IFACECFG_I2C_ADDRESS(). That breaks when ATCA_STRICT_C99 is enabled because the interface union is named cfg in that mode. This is now fixed.

2. SPI HAL and Zephyr v3/v4 compatibility
   The SPI HAL was still using the old spi_cs_control fields (gpio_dev, gpio_pin, gpio_dt_flags). Those were deprecated in Zephyr v3 and removed in newer Zephyr releases. The code now uses gpio_dt_spec (.gpio.port, .gpio.pin, .gpio.dt_flags), which is the correct path for modern Zephyr.

3. SPI HAL heap allocation
   The SPI HAL was using malloc()/free() directly. That is not appropriate for Zephyr module builds, especially on bare-metal configurations. It now uses hal_malloc()/hal_free().

4. SPI HAL sizeof() bug
   memset(hal_data, 0, sizeof(hal_data)) was zeroing only the pointer size, not the struct. Fixed to use sizeof(*hal_data).

5. SPI HAL release leak
   hal_spi_release() was not freeing the hal_data allocated in hal_spi_init(). Fixed.

6. SPI HAL logging
   Replaced printf() with printk() for Zephyr builds.

7. zephyr_options.cmake Kconfig-to-CMake propagation
   Some options were never propagating because the mapping logic assumed every CMake option name used the ATCA_ prefix. That is not true for options such as MULTIPART_BUF_EN, ATCACERT_COMPCERT_EN, ATCAC_SHA384_EN, etc. The mapping now uses the exact CMake option names.

8. Redundant Zephyr detection in lib/CMakeLists.txt
   The subdirectory lib/CMakeLists.txt was redundantly calling project() and find_package(Zephyr) even though the root CMakeLists.txt already handles Zephyr detection. That extra processing has been removed.

Zephyr coding standards

• Kconfig: Rewritten to follow Zephyr Kconfig style using menuconfig, an if CRYPTOAUTHLIB guard block, proper depends on I2C / depends on SPI, and standard help-text formatting.
• CMake: Normalized SET to set and cleaned up formatting in the Zephyr-specific files.
• C code: Verified that the modified Zephyr HAL files use C89 comments, braces on control blocks, and remain consistent with Zephyr expectations.

Test suite added

Added tests/zephyr/build_verification/ with a ztest-based suite that verifies:

• config header generation (ATCA_HAL_I2C, ATCA_ATECC608_SUPPORT defined)
• status code linkage
• HAL delay function linkage
• mutex lifecycle (create -> lock -> unlock -> destroy)
• mutex NULL-guard behavior (ATCA_BAD_PARAM returns)

This also includes testcase.yaml for integration with Zephyr's twister test runner.

Platform verification

All non-Zephyr platform build paths remain functionally unchanged. The Zephyr-specific logic is gated behind if(ATCA_ZEPHYR_SUPPORT), while the existing non-Zephyr path remains in the else() branch.

Verified with actual builds:

• Windows (MinGW, HID HAL): ✅ Clean build
• Linux (GCC 13.3, I2C + SPI + UART + PKCS#11 + TNG + certs): ✅ Clean build
• Zephyr 4.2 (native_sim): module is detected correctly and the CryptoAuthLib Kconfig symbols resolve correctly

For the Zephyr test build, the only remaining failure in the local tree is unrelated to this PR: the Zephyr checkout itself has pre-existing NXP RW6xx Kconfig warnings (MCUX_ELS_PKC, MCUX_PSA_CRYPTO_DRIVER_ELS_PKC, MCUX_PSA_CRYPTO_DRIVER_ELS_PKC_THREAD defined without a type), and Zephyr aborts on those warnings before compilation. The CryptoAuthLib module itself is loading correctly.

Supported-platform impact

I also checked the broader supported-platform impact carefully:

• Linux: directly built and verified
• Windows: directly built and verified
• macOS: no HAL changes and no functional change to the non-Zephyr build path
• Harmony / ASF / START / ESP32 / FreeRTOS: no HAL source changes for those platforms, and no functional changes to their build paths

So the net effect of this update is:

• Zephyr: fixed and strengthened
• Windows/Linux: directly verified
• Other supported platforms: unaffected by code-path review

@Srinivas-E this should now be in a much better state for review against the upcoming CAL release. Happy to adjust anything further if needed.