hi everyone, I struggled with SPI communication the last weeks. The following things are going wrong with my spi port:
unstable MISO receiving with connection above 15cm. with euxo I have the problem, that axoloti stops to receive right adc values if some longer cables are connected to euxo. This also happens if axoloti is mounted on a breadboard and some longer jumper cables are connected to the SPI pins. I know that this kind of signal connection should be as short and direct as possible. I don't own a digital oscilloscope to debug the slew rates of rising and falling signals. with a 74hc14 hex schmitt trigger nearby axoloti's spi pins I can run signals over 30cm connections without any issues.
without any modification on my test setup the MOSI ports starts to show strange behavior…
After transmitting the first of three spi transaction the mosi port stays in the position of the last bit which is sent (only bus pirate is connected to axoloti - MOSI = blue line)
I don't think that violates the SPI protocol, but is expected behavior. Is there no protocol decoding in the bus pirate software? If not, perhaps check out the sigrok project.
What's the clock frequency you're using? Is the SPI configured for the right mode? Data valid on falling edge clock versus data valid on rising edge of the clock. Using the wrong configuration way will make it unreliable. Another possibility is signal reflections - most critical is the clock line, a series resistor can attenuate those.
Which chip is driving MISO?
And yes, an oscilloscope, analog or digital, would be helpful to validate signal integrity, a logic analyzer does not reveal this.
I think if you'd blow up a gpio pin, that gpio would not function anymore - at all. It's unlikely to damage the spi logic inside the microcontroller without damaging the gpio input/output driver transistors.
thanks for hint with sigrok project. I'm using SUMP and the build in spi analyse function to debug SPI communication.
The only ICs on MISO line are two MCP3208 adcs which are controlled by separate CS lines.
I tried different spi modes. the one from the picture above is: CPOL=0 CPHA=0 SCLK=FPCLK/256 format=LSB
only axo and euxo pcb the max. working clock freq. for SPI is FPCLK/16. with 74hc14 (2xinverting before SPI ICs) and 4 devices on SPI bus with a sum of 30cm connection lines the max clock freq. is around FPCLK/64.
for mcp3208 spi communcation the datasheet say that I have to choose between CPOL = 0, CPHA = 0 or CPOL=1, CPHA=1.
The one which is printed out by axo patcher console only axo+euxo core (spi connection traces = max. 12cm). the second turn is with bus pirate sniffing communication(+ max. 15cm of spi connection).
axoloti setup spi mode 0, FPCLK/256, format=LSB and spi commands are send/received synced with "spiExchange".
I supposed this too. therefore I tried the schmitt trigger to clean up the signals and reduce the slew rates to a minimum of time. I also tried some small caps (10pF,22pF,1nF,10nF) and resistors (10R, 22R, 100R, 1K, 10K) in series as lp filter or single on miso and clock line but no improvements. I've read some things about "wellenwiederstand" (engl. wave resistance?), hf-trace layout and rf filters on this documentation and many thread at mikrocontroller.de the current euxo spi trace layout is not ideal (gnd is between every trace but long trace distances and one via per trace).
So I cut the clock trace at the start and end point on the pcb and soldered a single wire from axoloti directly to the clk pin of the mcp3208 socket (white cable).
after this I can also connect the bp cable to the unit and receive right values…so this wire (dia. ~1,1mm) improves the stability of spi communication.
but if the bp is also connected, axo received weird messages on mosi. the bp receives spi message correctly on the longer connection if only this device is connected to the spi line.
other spi ICs like 74hc595 which tested in combination with the euxo setup works without any issues. So MOSI/SCLK transmitting is working.
my analog osci (hameg hm203-6) don't have any storage function. A cheap DSO osci is on my ordering list for a long time.
I can confirm that the axoloti and mcu is very tough against little mistakes.
edit1: I tried to use the Low level SPI driver (spi_lld_init etc.) but can't get it working.
Even without storage, an analog oscilloscope is very useful, just make the adc readout repeating 5 times a second or faster, trigger on CS falling edge or CLK, watch CLK and MISO. Not practical for decoding, but fine for observing rise/fall time, overshoot, ringing, 0/1 levels.
Also exclude issues caused by the presence of the 2nd ADC on MISO, if they're in a socket, remove one to verify.
yes, e.g. checking signal quality over time is a bit difficult but here are some picture of the CLK at FPCLK/256. Osci time/div setting is at 0,5µs/cm. So rising time(tges) is around ~70ns.
the short low signal on mosi at the middle of the screen is because the read voltage is a bit a bit jittering so adc value is between 0x7FF and 0x7FE. if a probe from the osci is connected to the euxo+axo the axo stops to receive the right message but adc is sending right values on mosi (see pic. above)
I have one euxo core pcb with only one adc without any other components on the pcb. the necessary wires from axo are soldered directly to the socket pins. this solution don't work neither. it's shows the same behavior like the different other units.
I also assume the clock channel vertical amplifier of the scope is set to 2V/div and the MISO channel to 5V/div?
Is DGND connected to AGND on your Euxoloti board? Generally I think there is something else wrong that is far less subtle than signal reflections. If that white wire makes a difference, something is extremely unstable, not what I expect from not-super-high-speed spi.
I just stumbled over this: the MCP3208 datasheet says "MCU Transmitted Data(Aligned with fallingedge of clock)" and "MCU Received Data(Aligned with risingedge of clock)" I think that's odd, notspi standard and 'd explain the unstable data reception as you are experiencing...
Check the STM32F4 reference if it is possible to configure different clock phase/polarity for transmit and receive, but I did not find such configuration at glance. I was thinking receiving with the uart would be an option, but only allows up to 9 bit data, not the 12 bits that are required... The only remaining options I see is bit-banging the mcp3208 or involving a 2nd spi configured for the other phase for reception, slewing the MISO in analog domain, or using a toggle flipflop to double-pump the spi data, but presenting only half clock speed to the mcp3208. But none of these are elegant solutions... Perhaps worth searching the internet for other projects that have interfaced an MCP3208 with an STM32.
ups sorry, yes I mean MISO (Master In Serial Out).
sorry, yes signal high level is = VDD. and osci is set up like you wrote.
the euxo unit with white pcb and white clock wire has one signal GND plane. the newer rev. has AGND and DGND separated. AGND and DGND are rooted together at the AGND pin of each ADC and one single short trace is connected to the rest of the GND plane. this is done nearby the eurorack power header and vreg for axoloti. in the org. new euxo layout, the adcs and op-amps have their own 3,3V vreg. vref for adcs is token from axo VDD filtered by a 10R resistor. for further tests I did a solder bridge between Vref and VDD and removed the 3,3V vreg so the whole ICs are powered by axo's vdd pin. I posted the pics of the layout and eagle files at the euxo thread.
what about the header which is labeled "X3". axoloti schematic say that it's SPI3 bus. Is this one used for anything? if it's free I will check this spi bus for connecting further extensions (spi IC) to the euxo/axo unit. an additional cheap stmf1 (bare or as maple mini clone) or atmega328 running in I2C slave mode would also be possible and reduce part cost for expanding I/O controls. only cv in have to be read as quick as possible…this signals should be connected directly to axoloti for min. of latency.
Before posting this issue else on the internet I want to ensure it's special with axoloti and coding. I will post my issue at ucapps forum. they're using stm32f4 and mcp3208 with long ribbon cables. maybe they can tell what the reason for this strange behavior.
but if anyone else here have some troubleshooting hints, please post them here.
It is "reserved" for Axoloti Control. If you add a microcontroller you can just use the available SPI on GPIO, right? Current firmware already occupies spi3, so you'd need to fork the firmware.
Certainly worth checking the ucapps code that handles the mcp3208.
yes, this would solve my problem and is my plan be. By using the arduino fw I could easily org. planed features like encoders and oled screen. the microcontroller would act as a kind of classic midi controller.
can you or some one else move this thread to an other category so people can join the conversion. and thank you again.
I moved it to Hardware because it fits better here than the general Helpdesk category. I believe the Hardware category is as open as any other category for joining the conversation?
