OpenIMU300ZA SPI CLK

Hi,

I'm attempting to read some accelerometer values out of the 300ZA using SPI. The 300ZA was connected to a Teensy 3.6 (wiring checked and checked again) but no registers could be read successfully. After further checking, an osciliscope was deployed, and strange behaviour on the CLK line was discovered. Further digging showed that this line seemed to be being driven by both the 300ZA and the Teensy.

In the following screengrabs, Yellow = clock, Blue = chip slect, Green = MOSI, Red = MISO. Please disregard the fact that MOSI (Green) is far too small, this is a fault on the probe.

As we can see, the Teensy puts chip select low then a read command is sent over MOSI. The 300ZA makes no attempt to respond, presumably because the clock is not behaving properly?

With the 300ZA disconected from the Teensy, we see that the clock oscillates between 0 and 3.3V as you'd expect.

With the 300ZA connected to the Teensy, the clock oscillates between 1 and 3.3V.

If we disconnect the teensy clock out from the 300ZA clock in (leaving all other pins connected), then measure the 300ZA's clock in pin, we see the clock line is held high and occasionally oscillated.

Is it normal for the SPI clock pin (pin 3) on the 300ZA? It seems like odd behavior to me since this pin is supposed to be an input? I am assuming it's an input from the 300ZI datasheet, as I was told in this thread that the 300ZA is identical to the 300ZA. This issue has caused me to dig even deeper for a 300ZA datasheet, and I was eventually able to find an archived one here. It seems to imply that the SPI clock pin (pin 3) on the 300ZA is in fact an output?!

Any help on this issue would be much appreciated.

Cheers,
Tim

1. confirm SPI is supported:
   Pls refer to below link, and i need to confirm your FW version which maybe not support SPI now.
   https://forum.aceinna.com/topic/182/openimu300za-docs-missing/2
   2.confirm pin_7 is SPI mode connection:
   Pin 7 needs to be grounded (LOW) upon unit startup to force unit into UART interface mode. To force unit into SPI mode this pin needs to be either unconnected or connected to the input or external device
   Clock is created by master node, 300 is slave. pls go through all details in above link.
   especially topic_7 and topic_10 for you, in popular questions top link

Hi cek,

thanks for getting back to me. I've backed up my FW by connecting the 300ZA to a computer using an ST-link V2 and wiring up SWCLK and SWDIO like this.

However, I don't seem to be able to connect to the Aceinna Developer site using this setup: if I download the IMU Server Ready To Run (Windows) and run it, the program starts a websocket server but never finds my device. I tried downloading the python version but there doesn't seem to be a server.py file in the downloaded folder as per the instructions? Do I need the evaluation kit to use ANS web? I can't get NavView to work either, I presume it also needs the EVK?

Perhaps you could tell me what version my FW is by looking at the binary? I've uploaded it here.

I can confirm that I've tried pin 7 both disconnected and driven high, neither work.

Could you provide me with the latest stock FW for the 300ZA for me to install, or if I build an example from the OpenIMU Platform in VSC will that work with SPI, assuming FW version is the issue?

Cheers,
Tim

Hi cek,

quick update - I've built the compass example firmware on windows and flashed it to the 300ZA as per the Top Topics thread. I think this should mean we can rule out firmware as the issue - presumably all the examples now support SPI.

When I connect the 300ZA to the Teensy, SPI still doesn't work. Hooking up the oscilloscope to the SPI Clock Input on the 300ZA (when the Teensy is disconnected) we still see that the pin is being periodically driven. My best theory is that the 300ZA is in UART mode even though Pin 7 is not grounded on startup. It doesn't seem to matter if Pin 7 is driven high, low or left floating, it's always the same behavior.

Does this sound like a reasonable theory to you? I've had a quick look through the FW to see if I can force SPI mode in code but not managed yet. Do you know which files I might need to change?

Cheers,
Tim.

I cannot download your BIN file, but I can now confirm that your FW is not support SPI, which is default FW by factory(if you did not upgrade before).
Now you need to upgrade only FW of the unit, let us use ST-Link to upgrade directly:
Pls download IMU_1.1.3 FW for 300ZI in below link:
https://developers.aceinna.com/code/apps
and upgrade only the new FW_1.1.3 with ST-Link: like topic_9 in below
https://forum.aceinna.com/topic/93/top-topics-of-common-operations-with-openimu-products/2
wait your feedback.

Hi cek,

I can confirm that firmware was the issue in the end, that FW update has got it going nicely! Thanks very much for the help, hopefully this paper trail will be useful for other IMU300ZA owners.

Cheers,
Tim.

a good news, thanks a lot for your question and feedback.