3137 PGE SPI3 Mode Issue with DS3234N

John,

I googled for a DS3234 datasheet and it didn't mention SPI modes - so I'm assuming you didn't just go by the 'mode' number but checked the timing diagrams. I'm not sure everyone uses the same convention for SPI modes..

If that is the case I would ask what frequency are you running? If you slow the SPI clock down a bit and it starts working in modes '1 and 3' then it's likely a timing problem ... not enough time because of the SPI clock frequency might push data valid into a different phase of the clock making it appear that the mode is different, when in fact this would be 'dangerous' because this type of delay would change w. voltage, temp, and device to device.

Best Regards,
Anthony

Just eyeballing the spec - it looks like 500KHz or 1MHz would be pretty safe clock frequencies to try (looks like they'd give you lots of margin) when trying to determine the phase/polarity... If you're running at more than 4MHz that is out of spec for the RTC according to the datasheet I found. That's kind of slow compared to the TMS570 SPI frequency so maybe it's just that.

Hello Anthony,

My SPI CLK is 2MHz - and I have attached the cover of the datasheet - please look in the lower right corner - you'll see what it says regarding bus speed and modes. 

Datasheet can be downloaded from this page:

Thanks,
John

Hello Anthony,

I am definitely seeing a change on the SIMO signal after boot time - on pin 52. I realize TI has a half-duplex mode - but I didn't think that was enabled.

I will go through the code and try to see if something is reconfiguring the SPI3 I/F out from under this app - but I did change the CLK speed to 1MHz on the SPI clk and same result so far - but this change on the SIMO signal needs to be looked at.

I've looked at it closer with a LA and scope to verify that it is indeed changing from the time the app boots to 'run-time'.

By change I mean the voltage level seems to be below what it should be after boot time.

Regards,
John W.

Hi John,

To me it looks like you would use our Clock Mode Polarity=0, Phase=0 with this chip.

It would be normal to see a small dip (~100mV or so) on the pin as the device boots.
During reset and immediately after, the pin is 3-stated as the default configuration is GIO mode, and input.
In that mode the pullup or pulldown sets the voltage on the pin. Usually this won't be as low of a voltage on the pin
as you will see when the pin switches to an output and actively drives low. (This should occur when you change the pin
function from GIO to SPI mode during initialization.)

Assuming I am understanding you correctly as above - I doubt that this is a problem. If you see the pin voltage changing by a lot more - so that it's crossing through one of the thresholds like VIL of the RTC chip then maybe there's something to it.

Not sure what to suggest past this at the moment.

Thanks and Best Regards,
Anthony

Anthony,

Yes, that is what I am currently using - should be SPI 'Mode 0' - works fine.

I must be seeing the tri-state issue here - I thought something was wrong but the interface is working fine. I was trying to explain why Mode 1 and 3 weren't working but 0 and 2 were.

Well, like I said in the OP - Mode 0 and Mode 2 work.

Thanks,
John W.

John,

Ah ok. So then what you are seeing here is that we do not have 'SPI Mode 0,1,2,3'.

We have Polarity=[0|1], Phase=[0|1], and polarity 0, phase 0 is not necessarily what Dallas (or anyone else) would refer to as SPI Mode 0.

You have to match the modes up by looking at the timing diagrams.

Best Regards,
Anthony

Anthony,

Yes - Dallas/Maxim also talk about it here:
www.maximintegrated.com/.../502

Regards,
John W.

Hello Anthony,

This part also only seems to work in 'compatibility' mode - something worth noting.

Regards,
John W.

John,

Not sure of the last statement. Compatibility mode versus Multibuffered modes of the MibSPI shouldn't change whether or not it can communicate with another device at this wire level.

Hi John,

Just want to check if there are any open issues here or if we can close out this thread.

Anthony,

I have the part working. I imagine it is more of an issue of semantics. I usually use the definitions by Total Phase - since they are the recognized industry authority regarding I2C, SPI (mode definitions), CAN, etc. I think it is long overdue for any of us to say things like, oh, my SPI Mode 0 really means your SPI Mode 1 or anything even close to that where we aren't both using a recognized definition that is in agreement.

The modes on this page is what I go by:
www.totalphase.com/.../200349236-SPI-Background

Regards,
John

Hi John,

Yes, but we have to be concerned about changing terminology for existing customers - this same SPI has been used on the TMS470R1x, TMS470M, TMS570 and even some DSPs.

And did you know that it's possible for documentation to oscillate? believe me it's not fun when that happens.