SPI access in LoRa-e5 and im880b? #19025
Comments
benpicco
added
the
Type: bug
That's a good starting point! to find the offending commit? |
|
Part of the issue is that RIOT developers are providing patches that break the whole system until the last update is provided, so the first step of bisect already fails with so the final set of commits must be identified before the compilation can be completed and tested. Thanks. |
|
I hope there are not too much of those - you can use |
|
A lot of different issues seem to overlap. So far I have on the im880b with I cannot bisect much further as I always get stuck with a version of RIOT that is unable to compile with the proposed hash so the proposed hash above are the only ones that lead to a successful compilation (not even talking of a functional system!) |
Do you mean that in a PR, the individual commits are not necessarily buildable? |
|
Not sure what I am doing wrong, but already the first compilation fails when could be the newer gcc ( |
|
Yes it looks like a new warning in GCC 12. I think this should work, to ignore address warnings: |
|
Thank you all for your help. I reached a functional version with the following bisect sequence which I am afraid is conflicting with #18295 when multiple im880b boards are just not communicating over RS232 after reset (I was given a dozen im880b boards with half working through RS232/stm32flash programming and the other half working when programmed by ST-Link/openocd ... we suspect clock initialization issues but have not solved this problem either, preventing the identification of the faulty SPI CS# definition on this board). Indeed the offending commit 195b7e6 mentions rework of the stm32l0l1 clock configuration and is dated one week later than the initially identified c14d7ec which was the focus of #18295 Thanks. |
|
OK I give up on the im880b, too many issues at the same time. I just stumbled upon a ST B-L072Z-LRWAN1 LoRa discovery whose communication remains functional to this day. By compiling with and transfering the binary file through the mass storage interface, the following bisect sequence where "good" means the SPI the final answer is |
|
Reading the source code I realise that the code actually works, the following message is merely informative: This is the source code: printf("Trying to initialize SPI_DEV(%i): mode: %i, clk: %i, cs_port: %i, cs_pin: %i\n",
dev, mode, clk, port, pin);
puts("Note: Failed assertion (crash) means configuration not supported");
spi_acquire(spiconf.dev, spiconf.cs, spiconf.mode, spiconf.clk);
spi_release(spiconf.dev);I think there should be another I'll do a pull request. However, the fact that the test pass doesn't mean that SPI works (right?). In the original description @jmfriedt says:
I don't have an oscilloscope to test. Then, how could I verify whether SPI really works or not? (For context what I want is to fix issue #18975 , thought that may be an SPI problem or something else). |
The way it's now it's easy to interpret that there was an error, when really there was not. As seen in issue RIOT-OS#19025 quite some time can be spent following a wrong clue.
The This does of course not check if the clock signal has the correct frequency. |
|
Well, I can confirm SPI works in the lora-e5 board, I got the sdcard working, see comment #18975 (comment) |
|
Connecting as loopback MOSI to MISO of the im880b (P7 to P8) does not return the transmitted byte using |
19156: core/compiler_hints: add likely() / unlikely() hints r=kfessel a=benpicco 19174: tests/periph_spi clearly say when init succeeds r=benpicco a=jdavid When the `tests/periph_spi` program succeeds the output can be interpreted as an error happened. This PR makes it clearer when it does succeed. ### Contribution description In `tests/periph_spi`: - Explicitely say that the init operation was successful - Rephrase the note to avoid misinterpretations ### Testing procedure Run the `tests/periph_spi` program. There is not much to test, just to verify the output, should be like this: ``` 2023-01-19 10:42:33,768 # Trying to initialize SPI_DEV(1): mode: 0, clk: 0, cs_port: 0, cs_pin: 0 2023-01-19 10:42:33,777 # (if below the program crashes with a failed assertion, then it means the configuration is not supported) 2023-01-19 10:42:33,779 # Success. ``` ### Issues/PRs references Issue #19025 Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com> Co-authored-by: J. David Ibáñez <jdavid.ibp@gmail.com>
The way it's now it's easy to interpret that there was an error, when really there was not. As seen in issue RIOT-OS#19025 quite some time can be spent following a wrong clue.
The way it's now it's easy to interpret that there was an error, when really there was not. As seen in issue RIOT-OS#19025 quite some time can be spent following a wrong clue.
|
Just to be sure: For This looks just fine to me (tested on current Also, Can you confirm that there is an actual issue? |
The way it's now it's easy to interpret that there was an error, when really there was not. As seen in issue RIOT-OS#19025 quite some time can be spent following a wrong clue.
When compiling the
tests/periph_spiexample for LoRa-e5 board or im880b, theexecution of
in the provided shell fails, preventing sending messages on the MOSI and CLK pins. This
used to work with tag 6bf6b6b where the expected result is
and expected signals are observed on the oscilloscope on MOSI and CLK pins. Has the API changed to initialize the SPI bus?
Thanks
The text was updated successfully, but these errors were encountered: