RM46L852: MibSPI in Slave Mode - Transfer Groups stay enabled, ONESHOT flag seems to be ignored

Hello Manuel,

When operating in slave mode, the trigger source and trigger event are not taken into account by the sequencer. Only chip select can trigger a transfer group. CSHOLD is supported in master mode only, and Oneshot is also not used by slave sequencer. 

Hi!

That's sad to hear. I wonder why this information is nowhere to be found in the reference manual, it rather contradicts the manual (e.g. my quote).

The link to the Hercules FAQ you linked in your answer is of no help either.

I'm also not so sure about the CSHOLD not working as you wrote. I think, at least in TG0, it has some function. The manual is quite inconsistent about it.

I found this chapter that is all about the CSHOLD in slave mode:

27.2.11.2 CSHOLD Bit in Slave Mode (Multi-buffered Mode)
If the CSHOLD bit in a buffer is set to 1, then the MibSPI does not wait for the SPICS pins to be de-
activated at the end of the shift operation to copy the received data to the receive RAM. With this feature,
it is possible for a slave in multi-buffer mode to do multiple data transfers without requiring the SPICS pins
to be deasserted between two buffer transfers.
If the CSHOLD bit in a buffer is cleared to 0 in a slave MibSPI, even after the shift operation is done, the
MibSPI waits until the SPICS pin (if functional) is deasserted to copy the received data to the RXRAM.
If the CSHOLD bit is maintained as 0 across all the buffers, then the slave in multi-buffer mode requires its
SPICS pins to be deasserted between any two buffer transfers; otherwise, the Slave SPI will be unable to
respond to the next data transfer.
NOTE: In compatibility mode, the slave does not require the SPICS pin to be deasserted between
two buffer transfers. The CSHOLD bit of the slave will be ignored in compatibility mode.

But then in 27.10.3 Multi-Buffer RAM Transmit Data Register (TXRAM):

Chip select hold mode. The CSHOLD bit is supported in master mode only, it is ignored in slave
mode. CSHOLD defines the behavior of the chip select line at the end of a data transfer.

and in 27.9.16 SPI Transmit Data Register 1 (SPIDAT1) - which is - to be fair - only used in legacy mode:

Chip select hold mode. The CSHOLD bit is supported in master mode only in compatibility-
mode of SPI, (it is ignored in slave mode). CSHOLD defines the behavior of the chip select line
at the end of a data transfer.

What is right and what is wrong now?

Are there any other features that don't work in slave mode???

Could it be that you cannot select the CS for a TG in slave mode and they are hardwired TG0=CS0 TG1=CS1 TG2=CS2 and so on?

Also I cannot get TG1 to work unless I also enable CS0 - not only CS1 (that is bits 0 and 1 of PC0 need to be 1?). The CS setting in the TGs in HalCoGEN seem to have no effect either, although they end up in CSNR (as 1<<cs inverted), in the control word of the TXRAM registers. From the manual it kind of reads like if you could use CSNR in slave mode to select which CS (or even more than one can be configured so that either one of them triggers the transfer). But then again when I set it to CS_NONE (that gives 0x3F in CSNR), I can trigger TG0 by setting the TGENA even with PC0 bits 0..7 set to 0 but not TG1.

What exactly does the CSNR of each block do when in slave mode (and CSHOLD is enabled)?

What I actually want to accomplish:

A non-Hercules CPU as a SPI-master needs to transfer data (e.g. 336 Bytes) to a Hercules-CPU which acts as SPI-slave. The master can set the CS0 at beginning of the transfer and deassert it at the end, not for every 16 bits assert and deassert it. As the data does not fit in one TG, I want to use 2 TGs of 112 bytes (56 words) each alternating. As I have access to the master, I can request the master to partition the transfer in smaller chunks each with CS and a small delay in between which I of course want to keep as short as possible.

My first solution was to enable the CSHOLD - the only way I found to work with the long CS is sadly to ignore it. Then I used only TG0 and made a quite long pause (18us) between the transfers to be able to read the data from the TG before the next transfer. That kind of works now.

But I don't like that solution, I would rather use TG0 and TG1 and in the first pause only disable TG0 and enable TG1 so that the next transfer can run while I read the data from TG0. Also the CS should not be ignored.

But I cannot get it to work, I tried a lot of fiddling around with the registers to try to understand what the SPI slave does but I don't quite get it. Even the first solution does not work when I just use TG1, something is different on TG0.

Please help! I wrote dozens of firmwares before so it cannot be just my incompetence :)

Manuel

If it is helpful, I can provide another example project for the dev-board which demonstrates the different behaviour of TG0 and TG1.

Hello Manuel,

Manuel Köppen said:

What is right and what is wrong now?

I will check the CSHOLD in slave mode (multi-buffered mode)

Hi !

A week has passed now and I am afraid of the topic closing automatically. That's why I'm asking:

Are you still working on an answer to my questions?

Best regards,

Manuel

Hello Manuel,

Sorry for late response, I will test tomorrow for sure.

From the other topic

and from reading chapter 28.2.6.7 MibSPI Slave in Multi-buffer Configuration of SPNU563A (different CPU though) I think it is now clear how the CSHOLD works with slave mode, there are multiple references to a "3-Pin Mode" which is the TI way of saying to ignore CS.

The references where it says "The CSHOLD bit is supported in master mode only" are just wrong. Chapter 27.2.11.2 is right about the CSHOLD.

And you can only use TG0 in 3-Wire mode.

So all the effects I saw in my test program are explainable now. There is now real point in messing around with it any more.

It is quite sad that the only way to receive more than 16 bits of data as a slave, when you have a "long" CS (uninterrupted between for example each 16 bits), is to turn off the CS in the MibSPI ("3-Pin Mode"), enable the TG0 early enough before the transfer (maybe check CS is inactive as GPIO) and then in software disable the TG0 as soon as the transfer is complete (you need to know the length beforehand) because ONESHOT is not working.

Or is there any other way?

The ONESHOT not working is mentioned nowhere and I think that needs to be documented urgently.

Best regards,

Manuel

Hello Manuel,

The following statement is correct (Chip-select is used as SPI functional pin)

27.2.11.2 CSHOLD Bit in Slave Mode (Multi-buffered Mode)

If the CSHOLD bit in a buffer is set to 1, then the MibSPI does not wait for the SPICS pins to be de-activated at the end of the shift operation to copy the received data to the receive RAM. With this feature, it is possible for a slave in multi-buffer mode to do multiple data transfers without requiring the SPICS pins to be deasserted between two buffer transfers.

If the CSHOLD bit in a buffer is cleared to 0 in a slave MibSPI, even after the shift operation is done, the MibSPI waits until the SPICS pin (if functional) is deasserted to copy the received data to the RXRAM. If the CSHOLD bit is maintained as 0 across all the buffers, then the slave in multi-buffer mode requires its SPICS pins to be deasserted between any two buffer transfers; otherwise, the Slave SPI will be unable to respond to the next data transfer.

If chip-select pin is not used (3-wire mode), the CSHOLD is ignored in both master mode and slave mode. The MibSPI does not wait for the SPICS pin to be de-activated at the end of the shift operation to copy the received data to the receive RAM

Hi!

Will this crucial information (that ONESHOT does not work in slave mode) make it into the manual or errata? Will this be fixed in a future chip revision (if ever one is released)?

According to the manual, it should work.

It took me quite some time to figure it out and it also complicates things that ONESHOT does not work. Let me explain:

I have to sort of tap into some SPI connection between a non-safety CPU and a sensor. The sensor is polled quite often but the Hercules only needs to get a value once in while.

Now I have to make sure that CS is inactive when I start the transfer by setting TGENA (because starting does not wait for an edge on CS, just an active).

But if the ONESHOT had worked, I could have just left the transfer running and whenever the data is received, the TG would disable itself and whenever the firmware has time to check it (I am obliged to NOT use interrupts), I would expect a completed transfer and perfectly valid and consistent data.

Not so with non-working ONESHOT. Now it could be possible that the transfer is running again while I read the data, so it can get corrupted or inconsistent data because of a mix of new and old data.

The only solution is to busy-poll the end of the transfer and then as fast as possible disable TGENA in software. Not very elegant!

Best regards,

 Manuel