Hi, first of all — thank everyone for their work on ProffieOS 8.10.
While experimenting with it, I ran into an issue I couldn’t solve on my own, and I thought this data might be useful to everyone. I’ve tried to narrow it down as far as I could. I’m not familiar with the internals of the Arduino-Proffieboard core, so some of my reasoning below may be off — if there are any mistakes in what I’ve said, please correct me.
What I’m observing
On my Proffieboard V3.9, simply having #include <SPI.h> in the build breaks audio. No SPI device is connected, no SPI function is called, and ENABLE_SPIDISPLAY isn’t even defined.
Since display/spidisplay.h includes <SPI.h> at the top, I think this means that ENABLE_SPIDISPLAY and audio cannot currently work together on the V3 — but if I’m wrong, I’d be glad to be corrected, in case there’s a configuration option I’ve missed.
Environment
| ProffieOS | 8.10 (official release zip, unmodified) |
| Board | Proffieboard V3.9 |
| Arduino-Proffieboard plugin | 3.6.0 |
| Arduino IDE | 1.8.9 |
| Tools → DOSFS | SDCARD (SDIO High Speed) |
I tried several V3.9 boards from the same batch and got identical results, so I don’t think it’s a bad board on my side.
Minimal reproduction
Starting from the stock default_proffieboard_config.h, adding one line to CONFIG_TOP:
#include <SPI.h>
No ENABLE_SPIDISPLAY, no display object declared, no display hardware attached.
Flash it, and audio is broken. Remove the line, flash again, and it works. That was the smallest change I could find that still reproduces it.
Symptoms
On USB power: continuous buzzing from the speaker. The board doesn’t appear to be frozen — the main loop keeps running (battery voltage still prints every 20 s, Motion disable. and I2C sleeping.. still show up on serial).
On battery power: no buzzing, but the speaker is silent and the board gets noticeably warm. The warming only ever happened with <SPI.h> in the build, never without it. My guess is that the amplifier is being driven by a continuously underrunning SAI FIFO and USB current limiting hides the power draw, but I’m speculating here.
Also seen: Failed to mount SD card. repeating much faster than the once-per-second throttle in common/sd_card.h. This may or may not be related — I didn’t chase it down separately.
dmamap output
I built with #define ENABLE_DEVELOPER_COMMANDS and used the dmamap command. If I’m reading it right, the printed value is the DMA request number (dma->channel >> 4).
Without #include <SPI.h> (audio works):
DMA1_CH2 = 7
DMA1_CH6 = 7
DMA1_CH7 = 7
DMA2_CH1 = 1
DMA2_CH6 = 5
DMA2_CH7 = 5
With #include <SPI.h> (audio broken):
DMA1_CH2 = 7
DMA1_CH6 = 7
DMA1_CH7 = 7
DMA2_CH1 = 3
DMA2_CH2 = 3
DMA2_CH3 = 4
DMA2_CH4 = 4
DMA2_CH6 = 5
DMA2_CH7 = 5
The line that stands out to me is DMA2_CH1: request 1 in the working build, request 3 in the broken one. DMA1_CH2/CH6/CH7 = 7 is identical in both, so the WS2811 side looks unaffected.
One other thing I noticed: #include <SPI.h> seems to take two channel pairs rather than one — DMA2_CH1/CH2 and DMA2_CH3/CH4. I wondered whether every SPI instance declared in the core gets instantiated regardless of use, and whether the second pair might overlap with what SDIO wants, but I don’t know the core well enough to say.
Closing
The reason I thought this was worth writing up rather than just avoiding SPI on my build is that the failure is silent, it warms the board up on battery power, and it’s triggered by an #include rather than by anything the user actively does with SPI. Someone experimenting with the display code could spend a long time looking in the wrong place.
Happy to run any further tests on my hardware if that would help — I still have the setup wired up. And thanks again for all the work you’ve put into this project.