SPI timing issue with max35101

Thread Starter

irmanao

Joined Apr 29, 2017
87
I've been trying to test the time to digital converter max35101 with an stm32f407vg6 microcontroller and am stuck for some reason. The timings for the SPI communication seem to be extremely strict for this device and with the stm32 chip i have available without an external crystal, correct communication seems impossible. For example from the time the CS line goes low i only have 40ns (max) for the clock line to start pulsing. My setup takes at the very least 3-4us. Is this something that could legitimately make the communication impossible. Max35101 chip should trigger an interrupt after a particular opcode but i haven't managed to achieve that yet.I know my question may seem stupid, as the datasheet states the maximum timing clearly, but i would like a second opinion on this.
thanks
 

Attachments

JohnInTX

Joined Jun 26, 2012
4,358
For example from the time the CS line goes low i only have 40ns (max) for the clock line to start pulsing.
You're misunderstanding the datasheet spec. Tcc (CE/ to SCK Setup Time) is specified as 40ns. max. This spec calls out the minimum time between CE/ and the first edge of SCK, not the maximum time before you have to start clocking. So as long as you are waiting at least 40ns after asserting CE/ before beginning the SPI transaction, you are OK.
 

nsaspook

Joined Aug 27, 2009
7,896
Check your SPI mode and connections.

https://www.maximintegrated.com/en/app-notes/index.mvp/id/6105
Connections
Of course, doing anything with the MAX35101 requires communicating with it. The MAX35101 has a standard SPI slave port that expects to be connected to a SPI master belonging to the host microcontroller. The MAX35101 SPI peripheral operates in SPI mode 1, which means that the SCLK circuit idles in a low state and that data is expected to change on the rising edge of the clock and be sampled on the falling edge.
 

Thread Starter

irmanao

Joined Apr 29, 2017
87
You're misunderstanding the datasheet spec. Tcc (CE/ to SCK Setup Time) is specified as 40ns. max. This spec calls out the minimum time between CE/ and the first edge of SCK, not the maximum time before you have to start clocking. So as long as you are waiting at least 40ns after asserting CE/ before beginning the SPI transaction, you are OK.
The very same parameter for a different chip is referred to as min. I still can't see how it's the other way around but i guess you are right. Moreover your explanation makes way more sense, it's just a bit confusing. I'll check the connections once more.

Also something a bit more general: is there a difference if i send 16 bits continuously (meaning with a continuous clock) and if i sent two 8 bits (with a small delay between the two)? As long as the said communication is done while the CS pin is asserted once.

thanks for the help
 

Attachments

Last edited:

nsaspook

Joined Aug 27, 2009
7,896
In general always send what the slave device expects in data, clock and CS sequences.

A quick read shows opcode commands are 8-bit and require CS to be deasserted after 8-bits.
Execution Opcode Commands
The device supports several single byte opcode commands that cause the MAX35101 to execute various routines. All commands have the same SPI protocol sequence as shown in Figure 13. Once all 8 bits of the opcode are received by the MAX35101 and the CE device pin is deasserted, the MAX35101 begins execution of the specified command as described in that Command’s description
Page 22.
https://datasheets.maximintegrated.com/en/ds/MAX35101.pdf
 
Last edited:

JohnInTX

Joined Jun 26, 2012
4,358
A quick read shows opcode commands are 8-bit and require CS to be deasserted after 8-bits.
True for 8 bit commands of course but don't forget that CE/ must remain low for the whole transaction. If you are reading/writing the 16 bit registers, CE/ must be low for the whole 24 bits.

For reading, drop CE/ and send the one byte opcode. Discard the MISO value returned (on DIN) when the opcode is sent then send 2 bytes of arbitrary data and read the 2 bytes returned for the 16 bit register value. Raise CE/ to complete the transaction. Fig. 14, pp25

For writing, drop CE/ and send the one byte opcode then send 2 bytes of data to be written into the register, then raise CE/ to complete the transaction. Discard the MISO values returned for all 3 bytes. Fig 16, pp26

It's pretty standard SPI for better or worse. For convenience, I've attached the datasheet. I couldn't get it to download from Maxim to work.

Pretty slick chip. Have fun!
 

Attachments

Thread Starter

irmanao

Joined Apr 29, 2017
87
I rechecked all the connections, re-read the datasheet but the chip still doesn't seem to want to interact. I know this isn't a frequently used chip but i would appreciate your help if possible. I first write to the configuration registers (picture from logic analyzer) and then write a particular opcode that should trigger an interrupt, but it doesn't. My circuit is as per the datasheet (circuit). I have connected an external pull-up resistor to the INT pin.
thanks
 

Attachments

mckenney

Joined Nov 10, 2018
98
I first write to the configuration registers (picture from logic analyzer)
Try reading something. You won't see any activity on MISO until you do that.
1) Read TOF1 at startup. The factory value is 0x0010, though there's a note about it being written to flash, so maybe it's something else now.
2) Read back TOF1 (or some other) after writing it, to make sure it did what you said. You may want to make this a regular thing, at least until you have the device under control.
3) One of the first things I do with an unknown device like this is write a little loop that reads all the registers. Some will be hard to verify, but there are usually a few you can check against The Book.

What are you doing with the /RST line? I don't see anything in the data sheet about an internal pullup.

As I recall, the STM32 follows the standard(-ish) terminology for Mode, so if it says [CPOL=0,CPHA=1] you can put that right into the SPI config bits.
 

Thread Starter

irmanao

Joined Apr 29, 2017
87
I have tried reading from the registers i previously wrote but the wrong value is read. I always get back the value 0xFFFF, reading the register before or after writing to it.
The RST line is connected straight to the stm32 as shown in the circuit i posted previously. At the beginning of the program i bring it low and then high again.
I believe the polarity and phase are correct as shown better in the picture i uploaded (opcode).
 
Last edited:

mckenney

Joined Nov 10, 2018
98
I have tried reading from the registers i previously wrote but the wrong value is read. I always get back the value 0xFFFF, reading the register before or after writing to it.
I would say that this is where you should be focusing. 0xFFFF tells me that the device isn't driving MISO (ever), which in turn implies that it hasn't noticed the read command. (It looks like the high-order bit is set in all read commands, and no others, so maybe that's a clue.)

Until you can get the device to drive MISO, you have no idea whether it's even powered.

Do you by chance have an analyzer trace from a read command? Also, what sort of PCB(s) are you using?
 

Thread Starter

irmanao

Joined Apr 29, 2017
87
(It looks like the high-order bit is set in all read commands, and no others, so maybe that's a clue.)
I didn't quite get that. Could you please explain?
Here's a trace from a read command of the ToF1 register.
I use simple jumper wires from the stm32 board to the max35101 soldered on an adapter pcb. The extra circuitry (oscillators, caps) is on a breadboard.
thanks
 

Attachments

Last edited:

mckenney

Joined Nov 10, 2018
98
I didn't quite get that. Could you please explain?
All I meant was that, if there were a startup thing with the first bit of the first byte, it might not recognize the Read. I don't see anything like that in your trace.

It seems to be ignoring your Reads. (It's possible, though I think unlikely, that it's just sending out all 1s.) That presumably means it's ignoring your Writes as well.

At this point I'd be (re-)checking the electricals. Vcc/GND (at the pins), /CE (set a breakpoint and make sure it goes low at the pin).I don't see any obvious way to "poke" it at the pins to get a reaction, since all the /INT enables are disabled at startup.

How long are your jumper wires? I've seen slew problems with not-short (say >6") wires at high speeds (say >4MHz). It might be worth slowing your SPI down for the time being, just to get that out of the way.
The extra circuitry (oscillators, caps) is on a breadboard.
I'm somewhat leery of breadboarded oscillator circuits (they tend to be finicky and rarely work for me) but I'm also not an Analog Guy.

That said, I don't see any suggestion that the chip Requires the oscillators to be running in order to talk on the SPI.
 

Thread Starter

irmanao

Joined Apr 29, 2017
87
The wires are definitely longer than 6''. I'll replace them. I've slowed down the SPI at 125kHz with the same results. I just hate when i have to battle with the chip for a couple of days while different chips work first try... Anyways thanks a lot for the help.
 

Thread Starter

irmanao

Joined Apr 29, 2017
87
One more thing. Could it be that i am not using a low ESR cap (see picture) for the bypass pin? Is the flash circuitry mentioned needed for the SPI communication?
thanks
 

Attachments

mckenney

Joined Nov 10, 2018
98
One more thing. Could it be that i am not using a low ESR cap (see picture) for the bypass pin?
I don't know. My understanding is that the Bypass cap on an LDO is for stability, but not basic operation. But keep in mind that I'm not an Analog Guy. It seems that you should see something like 3V at the BYPASS pin if the device is powered; that may be worth checking.
Is the flash circuitry mentioned needed for the SPI communication?
I looked for something like that yesterday, and I didn't find a statement one way or another. It does say that reset reads the config from the flash, but none of the config seems to control the SPI. I suppose it's posslble that a flash failure would hang the device, but usually the SPI is dedicated/independent logic.
-------------------------
All this time I've been seeing a pullup on MISO that actually isn't there. (I should clean my glasses more often.) That makes it a bit curious that MISO is Always high, not wafting around. This may be benign coincidence, but it might be worth (re-)reviewing how the MISO pin is configured in the STM32.
 

Thread Starter

irmanao

Joined Apr 29, 2017
87
I am measuring 0V at the bypass pin and i've started to think that the chip may actually be defective at this point. I might have damaged it while soldering it on the board or it came this way because i'm just trying to communicate with it, not do anything complicated...
 

Thread Starter

irmanao

Joined Apr 29, 2017
87
Changed the chip and it works perfectly now. Really don't know how it could be defective from factory, i must have damaged it somehow.
 
Last edited:
Top