MicroPython Forum (Archive)

We’re running a PYBD-SF6 project that does a bunch of I/O tasks and runs a control loop in an ISR. It starts out by importing roughly a dozen modules that are part of our codebase. It’s been running fine on v1.13-150 firmware compiled with upy since last November. Recently, I discovered that any other firmware I try breaks SPI communication. Have tested stock and custom-compiled firmwares across versions 1.12 through 1.14. With all the other images I’ve tried, SPI stops working almost entirely. Strangly, it still functions about 1% of the time, when it will perform a send and receive just fine. I thought I'd ask here before breaking out the logic analyzer.

After much trial and error, I found the issue arises after a certain amount of stuff has been defined during our initial imports. I wrote a simple program that just does SPI communication tasks. I then start testing by importing our modules, adding one module at a time. At some point, I’ll add a module to the import list, reboot, and SPI stops working. If I comment out stuff in the newly-added module, I can find a point where adding one more definition (constant, method, class, etc) causes SPI to stop working. I can replace the offending module with a completely different one and get the same thing to happen.

We’re not running out of memory. We have plenty of memory left when the system works with the one firmware that doesn’t exhibit this behavior (it reports being v1.13-150-gb7883ce74). It’s worth noting that this happens fairly early in the overall import process as well.

I’ve replicated this with code using both machine.SPI and pyb.SPI. I’ve been able to fix it by using machine.SoftSPI, which works fine on a number of different firmware versions. Naturally, I’d prefer not to use software SPI, though.

The lack of response suggests you are the first to encounter this problem. To get it fixed I suggest you create an easily replicated test case that fails when run against the latest build (V1.15). Then raise an issue on GitHub.

Thanks. That's a good suggestion and I can work on that. Replication seems to require another device with which to communicate via SPI. Is there a standard way I should approach this with a code submission?

A picture of an oscilloscope or logic analyser trace on the signals, a description of the fault, and a code sample should suffice. Can the failure be demonstrated with MOSI connected to MISO? Some of the machine methods allow simultaneous read and write. That would be ideal as it would enable easy replication.