M68EN360 SPI delay between read/write

[jagadishc]

Hi,

I am using MC68EN360 for one of the project. I wanted to interface ethernet chip (ENC28J60) using SPI with M68K.

I have configured the clock of SPI to 6.25Mhz and the SPI mode  '0' is set . The problem i am facing here is for the consecutive write (SPI write) there is a  delay of around ~500us(micro seconds) and same delay is observed for consecutive read (SPI read) as well. Due to this i am not able receive/transmit ethernet packets at faster rate.

I have looked into the usermanual of MC68EN360 did not find any information on the minimum delay between write/read. want to know is this the known behavior or any configuration issue.?

Thanks,

Jagadish  

[Hui_Ma]

Hi,

Please check MC68360 user manual chapter 7.12.5.5.1 SPI Receive Buffer Descriptor (Rx BD) & 7.12.5.5.2 SPI Transmit Buffer Descriptor (Tx BD) to set [CM] bit:

Wish it helps.

Have a great day,
Mike

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[TomE]

The "Continuous Mode" isn't what you want. As detailed in the manual, that lets the SPI interface continuously read something like an ADC, continuously reading a temperature or a voltage. The main code can then just read the "latest" value out of the buffer when it needs it.

Are your "Consecutive Reads and Writes" all from a large Buffer Descriptor? Are you asking the SPI controller to send a large buffer's worth? Or are you trying to send one byte at a time (unlikely)?

Are you sending bytes or 16-bit words?

Does your Ethernet controller chip require byte-cycles (chip-select deasserted between bytes), word-cycles (16 or 32 bits) or can it transfer hundreds of bits with one chip-select assertion?

This SPI controller looks pretty primitive. It can't control the peripheral chip-selects. You have to do that yourself with writing to a GPIO pin to set and clear the chip-select.

There's another point to consider. The CPM is powerful, but it is a processor in its own right, and has to execute code to get things done. This takes a lot of clock cycles for it to handle the descriptors and so on. What clock is the CPM running at, and can you make it faster? It is very likely that 500us is "as fast as it can go", especially if it is only running at the same 25MHz that the core is. 500us is only about 12 CPM clocks to handle the overhead.

25MHz is really slow for 2019. It was really slow in 1996 when you were meant to move to the MPC860 which could go faster (and support Ethernet).

Tom

[jagadishc]

Hi,

Correct we do not need continuous mode.Since we need to configure some of the ethernet chip registers before data transfer.

Initially we need to configure the ethernet chip registers using SPI before sending/ receiving the ethernet packets. To configure the ethernet chip each time a register is written SPI chip-select (CS) has to be asserted and reasserted. so we are writing 2bytes (address + data) for on CS assertion and reassertion. And followed by actual data packets of more bytes with one more CS assertion and reassertion for the actual data packets.

16 bit words for the register (address + data)

For registers to update ethernet chip requires word cycles (address + data). And for the data it can transfer hundreds of bits with one chip-select assertion.

yes we are using GPIO for CS.

We looked in the CPM module we were unable to find ways of configuring the CPM clock greater than the CPU32 core clock. Please do let us know by any way to configure the CPM clock. 

Yes 25MHz is slow for the current gen. MC68EN360 had ethernet module inbuilt for which we were using LXT905 transceiver which was working well. As we were not able find the replacement of LXT905 moved to ENC28J60.

Regards,

Jagadish  

[jagadishc]

Thanks TOM,

yes we got the same with CPM clock and as of now we have fixed the SPI clock to 6.25 MHz which is the max frequency.

with respect to little endian and big endian we have take care of it.

we have missed the 500kbps part of the data transfer for the SPI. and the delay between each transfer.

LXT905:

We were looking for the SIA (Serial interface adapter) as mentioned in the M68EN360 for the ethernet and thanks for the name SNI , i think both SIA and SNI are same. 

we definitely look  into SNI equivalent chip and try out. (takes some time to get from the order and test).

Thanks,

Jagadish

[TomE]

I'm pretty sure the "500 kbps" is a 25 year old typo in the manual. That has to be 500 kBytes/second, corresponding to the transmitted rate you're seeing. It doesn't make any sense in the "Master" section, as you have no control over the rate once you give a buffer to the SPI module. You can't slow it down unless you send one at a time, and why would you do that? It has to refer to the maximum "slave rate" the chip can handle, especially if using a higher clock rate (slave can use 12.5 MHz).

You'd be way better off finding a compatible PHY chip. You won't have to change any software in order to use it. Unless you need to handle some chip configuration.

But you've got about 25 years worth of technology to catch up on, which you don't need, can't use and don't want. But it will still cause you some problems.

The LXT905 only had one job to do (be a 10MHz PHY chip) and it did it well. Since 1995 we've had 100MBit and 1 GBit Ethernet, and so that why MII and RMII were invented. Some of these PHY chips are also multi-port Ethernet Switches which can connect 10 to 100 Ethernet themselves. There's probably more transistors inside some of these chips than in the whole MC68360!

If you can buy a very simple (1995 design) PHY that just does that then it should be easy. The TI DP83910A looks to be one of these if it is still available.

So any replacement chip you select is likely to have a lot of necessary options that have to be set somehow. It would be nice if you could do all this by mode pins, but they want to save pins as well. So you usually configure these chips through a weird serial interface, defined as part of the MII spec, and consisting of an "MDC" and "MDIO" pins. All Ethernet controllers built into chips provide and control these pins - all modern ones, but not the MC68360. It has two pins, like I2C, but it isn't I2C. It is like "Bidirectional SPI", but there's no Chip Select. You can probably bit-bang the pins if need be, or you might be able to program the SPI port if you have to.

The following is "generic experience" with other PHY chips. The chips you find that support this old and original interface may be easier or harder to use than the following. I'm just writing this in case you run into these problems I've had. If you can get the 28-pin DP83910A you won't have any problems. If you get the 48-pin DP83848 you'll have TWELVE strap pins to deal with.

Edit: Actually you would have a lot of problems with the DP83910A. It isn't a Twisted Pair adaptor, but the is made for the original Ethernet generation, where the interface was a 15-pin "D" connector called "AUI" requiring an external coaxial transceiver (10BASE2 "Thinwire" or 10BASE5 "Yellow Hose"). The DP83910A converts to AUI. You then need a separate DP83922 to get that to Twisted Pair. Also, if you look at the LXT905 you'll see it has two "Mode" pins. It connects to four DIFFERENT types of SNI interface. Yes, this "standard" had four incompatible variants, It could handle MC86380/AMD, Intel, Fujitsu/Seeq and TI. The LXT905 was brilliant because it could emulate the other four interfaces in the one chip. Anything emulating an Intel chip probably uses the Intel variant. The TI chips may only connect to TI chips. So which interface variant does the TI 83848 use? The only thing in the manual is the unhelpful "While there is no defined standard for this interface, it is based on early 10-Mb physical layer devices." I'd guess it is the TI variant and wouldn't work with your Motorola chip.

You're better off finding a way to use the chip without this serial port. So they usually have "strap pins" which you pull up or down during chip reset (to configure them), and these pins take on other functions after reset. So you usually put pullups or pulldowns on these pins to set the reset state. This is fine for pins that the chip uses to drive LEDs. It is also fine for signals going from the PHY to the Ethernet controller. Where it is problematic is when they use OUTPUT pins driven by the Ethernet controller to be pulled during reset. That requires the Ethernet controller to not drive these pins during its reset (or it will override the strapping). You can do that if those pins aren't dedicated (and can be GPIOs) on modern CPUs, but I don't know if this is the case on the MPC860. Hmmm. The only pins like this are TDX/TX and TENA/RTS.It looks like they're also GPIO pins, so you might be OK with this.

You should have last-time-bought a big box of LXT905s when you could. Google finds LXT905s for sale. You might be able to get enough to keep going.

Good luck.

Tom

[jagadishc]

Hi,

Thanks for the input. We have ordered DP83848I evaluation board to check the compatibility. we are waiting and check to see if it works well with M68EN360,  in the 68EN360 there is a option to set the endianess hope this is the only change if any in the software. will update on this once i receive and test the device. If this doesn't workout then only other left out option with this processor is the last-time-buy of LXT905. 

Thanks,

Jagadish

[TomE]

It is very unlikely you'll be able to get it to work.

The "Intel/Motorola" difference IS NOT a matter of the "Endian-ness" of the bytes. The Motorola/Intel/Fujitsu/TI seven-wire SNI Interface has four different and incompatible variants. I don't know what the differences are. I'd guess that the polarity of some of the signals is the reverse of some of the others. I'd also guess that the *TIMING* of the Clocks, Data, Collision and Enable lines are different as well. If you've been playing with SPI you'll know that there are FOUR different and incompatible variants of the only two wires in that standard in terms of polarity, and which edge means which. They're "standardised" as Modes 0, 1, 2, 3. The SNI "standard" managed at least FIVE different versions with those seven wires.

If all the manufacturers had done a complete job you'd be able to compare the full Ethernet signal timing diagrams in all of their manuals to understand the differences, and maybe then be able to design some hardware to convert between them. They didn't do that job. In the main they just said "connect the wires directly to this specific matching chip we've made", and left it at that.

If the LXT905 fully documented all four different "modes" that it supports, then you could do the same (maybe design converter hardware). And they DID. Starting on Page 27 of the Data Sheet they give all the different timing for the four different modes. For instance, Mode 1 and 2 (Motorola and Intel) have the transmit timing on the opposite edge of the transmit clock. The Receive Start and End timing is different. So is the Collision timing.

> If this doesn't workout then only other left out option with this processor is the last-time-buy of LXT905. 

I would recommend that as a first option.

Or moving away from the MC68360. How much is your project reliant on the QUICC part of that chip? Is it doing timeslot stuff? How much is the code reliant on the 68k architecture? You could go to Coldfire (but you're 10 years too late for that).

Tom

[jagadishc]

Hi,

We tried with DP83848 evaluation board and is working without any software change. There are some settings required in the evaluation board to set the DP83848 in SNI mode. Following are the settings.

AN_EN = pull low 

AN0 = pull low

AN1 = pull low

RX_DV / MII mode = Pull High

TXD_3 / SNI mode = Pull High

And for the SNI pins

RXD_0

RX_CLK

CRS

TX_CLK

TXD_0

TX_EN

COL

Since the voltage level of the DP83848 is 3.3 V and the MC68EN360 is 5V we have used logic level translator in between.

Thanks,

Jagadish

[TomE]

Good luck with that.I would guess that the DP83848 is probably using what the LXT905 describes as "Mode 4". You can compare the detailed timing specifications of those two parts to see if that is the case. You can also compare the timing with that on Page 10-78 and thereabouts in the MC68360 manual.

It looks like the LXT905 "Mode 1" (MC68360) and "Mode 4" (Texas Instruments) are very similar in terms of the signal timing. The other modes look to operate on the opposite clock edges to those two. The main difference that I can see (between 1 and 4) are that the Receive Timing is different. The data is expected to transition on a different edge, but is sampled on the same edge. I'd check that the timing is compatible, especially given the presence of level converters, AND that these will be adding delays to the reference clocks. It is probably fine.

Another minor difference looks to be the "SQE/Heartbeat" feature, which the LXT905 has a pin to enable/disable, but which the other one doesn't. That shouldn't cause any problems, but might depend on the MC68360 HBC setting. If the software set this bit and the PHY didn't generate it there would be a problem, but you've got the reverse - you can't disable it in the PHY, but that should work in either case with the MC68360.

Tom

[jagadishc]

HI,

Yes correct its not only about Endian-ness . phase and polarity is also included in the communication. Though we have not received the DP83848I and not tested the chip. some are still suggesting to test, we are waiting for the evaluation board. 

Parallel work is going on for the LTB (last time buy) as well.

We are in a position not to change the processor MC68360.  

Thanks,

Jagadish