How restart SPI interface in MCF52255/9

[kappa74]

Good morning,

I have a problem in Ethernet connection that stops SPI communication.

I don't understad what tied these two interfaces because the stacks are OK, the tasks return "no error", so I don't know why when the Ethernet communication fails (EIR=0x07FFFFE4), the SPI communicatio will stop. Do you have any idea?

However I noted that the struct info of the SPI has strange values after the attempt of sending message: TX_IN=27, TX_OUT=28, RECEIVING=1, ONTHEWAY=1, RX_REQUEST=1. The register QAR=0x01.

I tried to reset the interface SPI by the command IO_IOCTL_SPI_DEVICE_DISABLE and then re-enabling the SPI with the command IO_IOCTL_SPI_DEVICE_ENABLE and setting: TX_IN=0, TX_OUT=0, RECEIVING=0, ONTHEWAY=0, RX_REQUEST=0, QAR=0x11.

After these actions the SPI doesn't restart. Why?

Which are the actions to reset and to restart the SPI interface?

Thank you

Best Regards

Mirko

[TomE]

> (EIR=0x07FFFFE4)

That's an impossible value for the MCF52259 FEC EIR. The lower 19 bits of that register must be zero. So somehow you're not reading that register.

> The register QAR=0x01.

That's the least interesting ASPI register. It contains the address of the RAM that has last been read or written.

> the struct info of the SPI

That doesn't mean anything unless you say what software you're running that is controlling the hardware. Not everyone runs the same software. You're also describing your problem from the software side - what functions you're calling. You should read the source code and see what it is doing to the hardware, and compare with the Reference Manual.

If you read the note in the section "27.3.1 QSPI Mode Register (QMR)" you'll find that the software must not change the CPOL and CPHA settings after writing them once. It should be clearing the QDLR[SPE] bit and then setting it again.

It also looks like you've got some sort of software problem, and may be better off asking questions in the forum specific to that software first.

Tom

[kappa74]

Good morning Tom,

thank you for your answer.

I made the test with the SPI driver in MQX3.8.1 and the example software for interrupt SPI. I found that after a time not deterministic the software stays in the following forever (inside the function "uint_32 _mcf5xxx_qspi_polled_ioctl" )

        case IO_IOCTL_FLUSH_OUTPUT:                

        case IO_IOCTL_SPI_FLUSH_DEASSERT_CS:       

            while ((0 != io_info_ptr->RECEIVING) || (0 != io_info_ptr->ONTHEWAY) || (qspi_ptr->QDLYR & MCF5XXX_QSPI_QDLYR_SPE))

            {

            };  **** Waiting for completion ****

I use the interrupt SPI and call the  "flush()" function.

The hardware was OK but after a time of working it stops to work.

Any idea?

Thank you

Best Regards

Mirko

[TomE]

> Any idea?

A software bug. In MQX or the way you're calling it. Have you searched for a matching problem?

There was a bug reported in 3.7. I would guess this should be fixed or it may not be working at all.

QSPI Driver Bug?

>  while ((0 != io_info_ptr->RECEIVING) ||

>            (0 != io_info_ptr->ONTHEWAY) ||

>            (qspi_ptr->QDLYR & MCF5XXX_QSPI_QDLYR_SPE))

All three of those have to be FALSE for it to get out of that loop. So which ones aren't zero and why? That's the obvious approach to find why an "if statement" isn't doing what you expect.

The only hardware register is the QDLY one, waiting for the SPE bit to clear. Once that has been set, it will clear when the transfer has been completed. The only ways I can think of to have this not clear would be to program an "infinite loop" in the QWR, or to maybe disable the QSPI by writing QMR[BAUD] to zero. Otherwise it must finish.

"RECEIVING" and "ONTHEWAY" must be flags that are set by *OTHER* threads or by interrupt routines. It is up to the software to handle these.

So when it is locked up, WHY is it locked up? Which of those two variables and the hardware register is non-zero. Then found out why it is wrong.

Here's another interesting question that a search found:

Mutex with QSPI?

What happens if you have TWO MQX threads trying to control two separate SPI-connected devices through the one QSPI driver?

Nothing good. Nothing good AT ALL! Are you trying to do this?

Tom