This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

LAUNCHXL2-RM57L: 256 byte SPI to EMIF asynchronous transfer

Part Number: LAUNCHXL2-RM57L
Other Parts Discussed in Thread: HALCOGEN

Hi All,

I would like to receive 256 bytes from the SPI and transfer them via the DMA engine to an SDRAM connected to the EMIF interface.

Currently I have managed to exploit the SPI transfer group in order to asynchornously receive up to 128 bytes to the processor memory. However, I cannot receive more in a single asynchronous Rx because this is the maximum size of the trasfer group associated with the SPI interface.

Could you please let me know of the following two questions:

  1. Can the SPI transfer be DMAed directly to the EMIF bus?
  2. Can the SPI transfer be increased to 256 bytes?

All the best,

Angelos

  • Hello Angelos,

    Angelos Spanos54 said:
    Can the SPI transfer be DMAed directly to the EMIF bus?

    No. The data would have to be transferred between defined addressable memory or registers.

    Angelos Spanos54 said:
    Can the SPI transfer be increased to 256 bytes?

    As you noted, the MibSPI transfer groups are limited to a maximum of 128 MibSPI buffers. This is hardware limitation.

  • Hi Chuck,

    Many thanks for your response. The RM57L document refers to "Channel Chaining". Can we use the Channel Chaining feature to trigger a DMA transfer with the contents of the transfer group to the EMIF bus.

    All the best,

    Angelos

  • Angelos,

    To clarify, what are you meaning by EMIF Bus? Technically, I think the EMIF would be seen as expanded memory with a specified CPU accessible memory address. So, to be clear, DMA could transfer from a MibSPI RAM location to an address within the EMIF address range of the connected memory. Sorry for any confusion but to me this isn't transferring from memory to a bud but from memory to the external memory location.

    In regard to Channel Chaining, this is a fairly complex operation. I believe it should be possible, but I have never done it.
  • Hi Chuck,

    Thanks for the clarification. Yes I understand now. Initially, I wanted to transfer the data directly to a memory location other than the transfer groups. However, I now understand that this is not possible. The MibSPI will always transfer the data there, and I have to copy the data from there to another location.

    Also, is it possible to change the transfer group size dynamically, or is it done only during initialization? Ideally, I would like to be able to set the maximum during mibspiInit, and then be able to change it during run time.

    All the best,

    Angelos

  • Angelos,

    Theoretically, although I have never seen it donw, it should be possible as long as the MibSPI is idle at the time. Is the reason due to the fact there isn't enough MibSPI RAM to setup individual Transfer Groups for each block of data to be transferred or that there aren't enough transfer groups available? Having transfer groups for each of the individual blocks of data would be more practical and conventional regarding the MibSPI.
  • Hi Chuck,

    Many thanks for your support.

    I am now fine with the maximum size.

    The problem is that when I transmit an SPI message I want to have a configurable burst size. So I would like the burst size to be 1, 2 3, 4, ... 64 bytes. Is this possible via the transfer groups?

    All the best,

    Angelos
  • Hello Angelos,

    If I am understanding correctly, you would want to vary the TG size dependent on the payload size of the message to be sent in a specific TG. TO do this, I would recommend using the TG in oneshot mode (See the register description for the register TGxCTRL). Additionally, use the definition of PSTART in the adjacent TG to vary the length of the TG in use when neither TGx and TGx+1 are in use. To determine if a TG is in use, use the TG_IN_SERVICE field of register LTGPEND.

    Note that this is outside of the normal use case of the MiBSPI TGs supported through HalCoGen so it will mean a customization by you to implement it. Also take note, as I have mentioned before, I am not aware of this being done before so, although it seems feasible based on the MiBSPI description, we have no background on the effectiveness of such an implementation. Given, the amount of CPU interaction, I am not certain of the gain over the use of a standard SPI in interrupt mode.