Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to use SPI1 when enabled without SPI0 on cc13xx/cc26xx #25673

Closed
vanti opened this issue May 27, 2020 · 0 comments · Fixed by #25674
Closed

Unable to use SPI1 when enabled without SPI0 on cc13xx/cc26xx #25673

vanti opened this issue May 27, 2020 · 0 comments · Fixed by #25674
Assignees
Labels
area: Devicetree area: SPI SPI bus bug The issue is a bug, or the PR is fixing a bug

Comments

@vanti
Copy link
Collaborator

vanti commented May 27, 2020

Describe the bug
Similar to the issue for UARTs fixed in #25647, one is unable to use SPI1 unless SPI0 is enable in DTS.

To Reproduce
Steps to reproduce the behavior:

  1. Modify boards/arm/cc1352r1_launchxl/cc1352r1_launchxl.dts to enable spi1
&spi1 {
        status = "okay";
        sck-pin = <10>;
        mosi-pin = <9>;
        miso-pin = <8>;
        cs-pin = <11>;
        cs-gpios = <&gpio0 11 0>;
};
  1. Modify tests/drivers/spi/spi_loopback/boards/cc1352r1_launchxl.conf to use SPI_1:
    CONFIG_SPI_LOOPBACK_DRV_NAME="SPI_1"

  2. cd tests/drivers/spi/spi_loopback

  3. west build -b cc1352r1_launchxl

  4. west flash

  5. See error:

*** Booting Zephyr OS build v2.3.0-rc1-341-g2972cdc7632f  ***
Running test suite test_spi
===================================================================
starting test - test_spi_loopback
I: SPI test on buffers TX/RX 0x200000c5/0x200005d6
I: SPI test slow config
I: Start complete multiple
I: CS control inhibited (no GPIO device)
E: ***** BUS FAULT *****
E:   Precise data bus error
E:   BFAR Address: 0x40008004
E: r0/a1:  0x40008000  r1/a2:  0x02dc6c00  r2/a3:  0x10000000
E: r3/a4:  0x00006717 r12/ip:  0x00000009 r14/lr:  0x00003045
E:  xpsr:  0x61000000
E: Faulting instruction address (r15/pc): 0x00002f2e
E: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
E: Current thread: 0x20000178 (unknown)
E: Halting system

Expected behavior
The test should pass.

Impact
This prevents a user from using SPI1 without enabling SPI0, leading to slower boot time, higher power consumption, etc.

Environment (please complete the following information):

  • OS: Ubuntu 18.04
  • Toolchain (e.g Zephyr SDK, ...): Zephyr SDK 0.11.3
  • Commit SHA or Version used: 2972cdc

Additional context
Add any other context about the problem here.

@vanti vanti added the bug The issue is a bug, or the PR is fixing a bug label May 27, 2020
@vanti vanti self-assigned this May 27, 2020
vanti added a commit to vanti/zephyr that referenced this issue May 27, 2020
The power configuration is dependent on which SPI is physically used.
In order to allow DT_INST_FOREACH_STATUS_OKAY() to iterate through
instances without the assumption that index 0 corresponds to SPI0
(which would be incorrect in the case when only SPI1 is enabled),
we need to check the base address to identify which SPI is being dealt
with.

Fixes zephyrproject-rtos#25673

Signed-off-by: Vincent Wan <vincent.wan@linaro.org>
carlescufi pushed a commit that referenced this issue May 28, 2020
The power configuration is dependent on which SPI is physically used.
In order to allow DT_INST_FOREACH_STATUS_OKAY() to iterate through
instances without the assumption that index 0 corresponds to SPI0
(which would be incorrect in the case when only SPI1 is enabled),
we need to check the base address to identify which SPI is being dealt
with.

Fixes #25673

Signed-off-by: Vincent Wan <vincent.wan@linaro.org>
krip-tip pushed a commit to krip-tip/zephyr-local that referenced this issue May 30, 2020
The power configuration is dependent on which SPI is physically used.
In order to allow DT_INST_FOREACH_STATUS_OKAY() to iterate through
instances without the assumption that index 0 corresponds to SPI0
(which would be incorrect in the case when only SPI1 is enabled),
we need to check the base address to identify which SPI is being dealt
with.

Fixes zephyrproject-rtos#25673

Signed-off-by: Vincent Wan <vincent.wan@linaro.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Devicetree area: SPI SPI bus bug The issue is a bug, or the PR is fixing a bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants