Multiple SPIClass objects cause failure in version 3.0.2 #9939
Comments
|
Hi @oxothnk423, can you set Core debug level to "Verbose", and send the debug message? Maybe then we will have more info of what is happening. Also can you test if it will work with this slightly changed code? |
P-R-O-C-H-Y
added
Area: Libraries
|
why use two instances of the same bus and not one? Try what @P-R-O-C-H-Y suggested and use one instance of the SPI bus. |
|
Hi @me-no-dev and @P-R-O-C-H-Y, thanks for the replies! All help appreciated! Regarding the comment and code suggestion to use just one Class instance, yes, this does work. And if I only needed two manually controlled SPI devices, I would do exactly that. But as mentioned in the original post, I'm also using library-managed SPI devices, where the library is also calling spi->begin. If I create and initialize a single SPI object myself for some devices, but the library is ALSO calling spi->begin, I get a conflict. Add I'm likely going to add in a second library for yet another SPI device, so there may be up to three calls to spi->begin(). This is the conflict I'm trying to resolve. As mentioned, it worked fine in V2.x, but started failing with v3.x. For an abundance of clarity: I'm hoping my original code above is the simplest form to diagnose this error, but I can post longer code with the specific libraries if it's more helpful to see "the real thing". (and I'd be super happy to learn I'm trying to initialize SPI objects wrong (manually and via library)... so please correct me anywhere I may be mistaken. I'm just surprised the SPI communication was working so great in v2.x and now not in 3.x) Here are the requested debug messages: When I run the original [does not work] version with core debug set to "error", I get this message: [ 2110][E][esp32-hal-cpu.c:121] addApbChangeCallback(): duplicate func=0x42004d18 arg=0x3fc93204 Here is the full verbose output below.. Thanks for any help or insight you can provide! (not sure why it formats so big and bold..?) |
|
@P-R-O-C-H-Y will have a look why multiple begins would cause an issue, but in general we will fix it and you should use one instance of the class and call multiple begins, that will not cause issues. Using separate classes talking to the same hardware is a bad idea and for that to work, many things will need to change. |
|
Hi again,
So the issue does appear to be specifically when two SPIClass instances are present. In case 3 above, I was initializing my own new instance, and the u8g2 library was initializing the default static instance provided in SPI.h, resulting in two separate class instances to the same SPI bus. When only one class instance is present (case #4 above), you're correct @me-no-dev that multiple SPI.begin() calls works fine. (which is great, because each new library I use for a different device calls begin() on the default Arduino static SPIClass instance, so there wouldn't be an easy way around multiple begin() calls). So to summarize: Thanks very much for your attention and helpful comments. |
|
In this case, do you need to correct the example for the library? |
|
Hello, Due to the overwhelming volume of issues currently being addressed, we have decided to close the previously received tickets. If you still require assistance or if the issue persists, please don't hesitate to reopen the ticket. Thanks. |
Board
custom PCB
Device Description
ESP32-S3 FN8 with three SPI devices:
ICM 20948 9-axis IMU
MS5611-01BA03 barometric pressure sensor
192x64 monochrome LCD
Hardware Configuration
ESP32-S3 FN8 with three SPI devices connected to default VSPI (FSPI) pins (MOSI, MISO, CLK) and separate chip select pins.
Version
latest master (checkout manually)
IDE Name
Arduino IDE 2.3.2
Operating System
Windows 10
Flash frequency
QIO 80Mhz
PSRAM enabled
no
Upload speed
921600
Description
In ESP32 version 2.0.14, I was able to initialize each SPI device separately with its own SPIClass, even though they're all pointing to the same bus (VSPI in this case). This allows for unique settings (such as chip select pin) per spi device / class. In setup(), each device's class would then need a call to SPIClass->begin().
In version 3.0.2, it seems repeat calls to spi->begin() for the same spi bus creates a conflict or failure, such that the code hangs (with no error thrown) when performing a call to spi->transfer().
A simplified version of the code is below, which works on 2.0.14 and DOES NOT work on 3.0.2. The specific conflict I believe is the second call to spi->begin for the second device. If this line (imu_vspi->begin(...);) is commented out, the code compiles and runs without hanging (even though the SPI communication isn't as expected since the second device is now not set up properly).
There are ways to work around this if I was only using exclusively my own code, but some popular libraries (for example I'm using u8g2 for the LCD) internally handle their own SPI device setup. This makes it nearly impossible to avoid repeat calls to spi->begin on the same bus. (in other words, I can set up a single SPIClass to manage my other devices, or I can initialize the u8g2 library, but not both).
Is there a better way to approach multiple SPI devices on the same bus? I'd love to learn I'm just doing something wrong... I'm happy to take advice on alternative approaches. But this approach worked great in V2.x, so I'm surprised to see it failing here in v3.x when there were no listed breaking changes in the SPI API's (as far as I saw).
Sketch
Debug Message
Other Steps to Reproduce
As mentioned, this has worked correctly on 2.0.14. I am able to initialize 3 separate SPIClasses, all pointing to VSPI, and each with their own spi->begin() call, and also initialize a fourth u8g2 library spi object.... and SPI transfers worked flawlessly among all of them.
Now in v3.0.2, I only seem to be able to make a single spi->begin call, which thus enables only one SPIClass, not multiple.
I have checked existing issues, online documentation and the Troubleshooting Guide
The text was updated successfully, but these errors were encountered: