Help Needed: SPI Clock Signal Stuck High on Custom PCB with 48 MLX90393 Sensors (Hall Effect Device for Palm Rehabilitation)


Hello everyone,


I am currently working on my master's thesis, where I am developing a hall effect-based device for palm rehabilitation. The device is designed to assess and assist with rehabilitation exercises by measuring force applied through the palm. Here’s a brief overview of the project:


Project Overview:


Hardware Setup: I’ve designed a custom PCB that incorporates 48 MLX90393 sensors, which are hall effect-based magnetometers. These sensors measure the magnetic field and, using calibration, I convert those readings into force data.


Communication: The sensors communicate with a Raspberry Pi 5 using the SPI protocol. I use a single SPI channel for all 48 sensors.


Software: I’ve written the code for sensor communication, data calibration, and visualization of the readings. The code works perfectly, and everything was functioning smoothly until 2 days ago.



Problem:


Recently, I encountered a hardware-related issue that is preventing communication between the Raspberry Pi and the sensors. The SPI clock signal (SCLK) is always high, meaning there is no clock toggling, and as a result, the communication between the Raspberry Pi and the sensors is not happening.


This problem appeared unexpectedly, and up until 2 days ago, everything was working fine. I have double-checked my software and confirmed that the issue seems to be hardware-related.


What I’ve Tried:


Rechecked all connections and wiring on the PCB.


Verified the software, which hasn’t changed and was functioning properly before.


Attempted various SPI clock speed configurations and SPI modes, but the clock line remains high.


Inspected the Raspberry Pi configuration, ensuring that SPI is enabled and properly set up in /boot/firmware/config.txt.



What I’m Seeking:


I’d appreciate any insights or suggestions from experienced engineers or anyone who has faced a similar issue. Specifically:


Could this be a hardware failure, such as a damaged SPI pin on the Raspberry Pi or on the custom PCB?


Are there any tests I could run to further isolate the issue (e.g., specific pins to test with an oscilloscope or voltmeter)?


Any advice on troubleshooting SPI-related hardware issues would be greatly appreciated.



Thank you in advance for your help! I’m open to any suggestions or ideas that might help resolve this.



---


Additional Info:


Raspberry Pi: Model 5


Sensors: MLX90393 (48 sensors)


SPI Configuration: Single channel


Issue: SPI clock signal stuck high, preventing communication



Feel free to reach out if you need more information. I’m really hoping to get the device back up and running so I can continue with my thesis work. Thanks!



---

 

The RPi has two SPI ports. Have you tried the other port? The RPi (and most of the SoC processors) pins are not very robust when compared to a typical 8-bit 5vdc controller. Static discharge or overvoltage will kill them (latchup) in milliseconds. I/O buffers are recommended.
http://www.mosaic-industries.com/em...spberry-pi/gpio-pin-electrical-specifications



Fig. 1 Equivalent circuit for a Raspberry Pi GPIO pin. The input diodes are actually parasitic FETs which can not handle any significant current.

There are a few subtleties and notable features of the circuit:

• The internal diodes shown in the figure are not really substrate diodes, but they are actually parasitic FETs. Electrically, their I-V characteristic looks like a diode's, but with a greater forward drop and a more gradual knee. They may protect against low current transient events caused by transient out-of-range voltages applied to the pins, but they are not intended to protect against the application of voltages greater than the supply voltage or less than ground, even with an external series resistor. In brief, you should never deliberately forward bias those "diodes". Consequently, you can not safely place an external pull-up resistor to 5V on the I/O pin. That would forward bias a parasitic FET and owing to its poor internal impedance to the chip's internal power rail it may overheat, or worse, it may bias up parts of the chip to voltages greater than they can handle. So, don't do it!

 

IT HAS BEEN A WHILE, and I just now read this post for the first time.
My suggestion as a diagnostic process is to first use a meter and measure the actual output of the PCB. If it is not high, then suspect a connection issue. If that output is high, then disconnect it and see if it is still high, or if it is then low, the problem is either in the connection or at the receiving end.

 

A second suggestion is the check the power supply voltages because some times operation conditions may be borderline and a small change can "cross the line."