FRDM665SPIEVB SPI

[vmhb]

I have a FRDM665SPIEVB evaluation board and I have hooked it up to two master SPI busses on a micro controller, MCU,  platform. The MCU SPI busses are configured as masters, CPOL=0, CPHA=1, MSB first, 8 bits per transfer and enable active low. One bus is hooked up to the request bus and the other the response. No response is being sent after sending a request to read a register. 

I would like to understand if I can expect the board to respond to internal register accesses without any slaves connected and if there is anything more that needs to be done to wakeup the board before sending SPI requests.

[MarkFan]

Hi,

     I use some MC33665AEVB to replace the MC337774 and connect to MS33771C via TPL port 0.

     I could config MC33665A internal registers vis TLP3 protocol, however, the TPL2 message from MCU didn't send to TPL port 0. 

     Below are my setting value for reference.

     1. SYS_COM_TO_CFG = 0x5A64. 

     2. SYS_SPI_CFG = 0x1801.

     3. SYS_PORT0_CFG = 0x8f.

     4. SYS_EVH_INT0 = 0x3F00.

     5. SYS_EVH_INT0_OUT = 0x3.

     6. SYS_QUEUE_CTRL = 0x2.

    BTW, I  got GPIO0 = high, if I send TPL3 message to TPL port 0, but normal TPL2 messages don't output to TPL port 0. Don't know why?

    Thanks for any help.

Best regards,

Mark

[vmhb]

From your register settings my system is very different to yours. As a result I am not in the best position to help. Here are a few observations.

There is no timeout value set in SYS_PORT0_CFG. I have noticed that if this value is 0 and you queue commands things can get lost.

You say no TPL2 messages are output on TPL port 0. However you then talk about setting a GPIO. Before that stage I would expect to see device enumeration. Does that work?

[MarkFan]

Hi vmhb,

    Thanks for your reply. How is the status of your FRDM665SPIEVB? Have you fixed all issues?

    The setting values for MC33665A  internal register are according to  AN13640
MC33665A SPI Application note.

    The GPIO active high is a example, explain that MC33665A acts as I expect according to my setting value. 

    BTW, I don't understand what do you mean "device enumeration"? 

 Best regards,

Mark

[vmhb]

Don't know if the MC33771 is the same as the MC33775 but it has a SYS_COM_CFG register. On powerup this takes default values. Depending on the devices you have this will need to be written to on each device to configure it. DADD is located in bits 5:0. On startup this is 0 or unenumerated. The process of enumerating the devices centres around setting up this register.

[MarkFan]

Hi vmhb,

    Thanks for your reply.

    Previously I used MC33774, I can used STB pin to wakeup MC33771C.

    In this MC33665 TPL, I can wakeup MC33665 via CSNREQ, but cannot wakeup MC33771C.

    Any idea ?  Thanks for your help.

Mark

[vmhb]

MC33775 devices operating TPL 3 may be woken with a NOP command containing specific data bytes. Does the MC33771 have something similar for TPL 2? 

[MarkFan]

MC33771C has NOP command 

The No Operation (NOP) command allows the user to reset the communication timeout
timer of the MC33771C. If the pack controller has no new request for MC33771C
IC but does not want the MC33771C to reset (and lose its CID address), it can send a
NOP command to the MC33771C IC. The NOP command does not trigger any response
or operation from the MC33771C. Thus, the NOP command can be used by the pack
controller like a ping to prevent the IC from resetting itself.

Mark

[vmhb]

For the MC33775 this is not just a generic NOP. There are special data bytes specifically for wakeup. I would have thought there is something similar for the MC33771.

[MarkFan]

Hi vmhb,

     Much thanks for your time to read my issue and reply.

     I found that no data was transferred from the TPL port to 33771C.  Is there any way to check it?

Mark

[vmhb]

How do you know there is no data on the TPL port if you don't know how to check? Best way to check what is going on with the TPL ports is to use a NXP TPL sniffer. 

[MarkFan]

Hi vmhb,

    Thanks for your help.

    Just tell you a good new, I could get voltage data from MC33771C.

    If have a chance, let me buy you a drink.

Best regards,

Mark

[vmhb]

Thomas,

Thank you for getting back to me. The cables are very short, are not twisted pair, but I am running the SPI bus very slowly, 24KHz. I have hooked up a logic analyzer to the MC33665 development board and this is what I see. A request goes out on SPI0 to read register 0x10. Not sure if that is correct. I then wait for 100us between the two markers for 0 and then try and read a response. As you can see the data is all 0 and MISO does not move. Oddly some time later MISO changes outside of CS. Any idea what is going on here, some kind of timeout? 

[vmhb]

For further clarity there is a 12V supply connected to J6 so J8 3-4 and VIO selected at 3V3 so J13 5-6. There are no jumpers on J14 and all the switches at SW2 are off.

SPI0 CS  => J7 P1

SPI0 MOSI => J7 P7

SPI0 CLK => J7 P3

SPI1 CS => J16 P1

SPI1 MISO => J16 P5

SPI1 CLK => J16 P3

[vmhb]

Further studies appear to show the MC33665 is permanently in STANDBY. Pin J1 pin 18 STB_OUT is being monitored and is always high. J7 pin 1 SPI_REQ_CS is being toggled to try and wake things up and in addition K4 pin 15 CSN_REQ is also being monitored. What else needs to be done for J1 pin 18 to get to an ACTIVE state?

[vmhb]

It seems that my problems were caused by CFG0 being switched to use the external XTAL. If I move SW2 0 to the on position I can see the responses.

[vmhb]

Can anyone explain why the chip will not come active, STB_OUT, if the configuration is set such that the external XTAL is used. I appreciate it is supposed to take longer to come ready using the external XTAL but I can never get it to come ready. Does the wakeup need to be different? 

[TomasVaverka]

Hello Simon,

Please check your HW configuration, is it done according to the instructions in the UM11734 - Hardware user manual for FRDM665SPIEVB?

Best regards,

Tomas