OMAPL138 workaround for known issue: SPIDAT0 is only able to handle max 16 bit

Hi Christian,

Thanks for your post.

Yes it is possible for a SPI module to trigger the DMA via the XEVT (transmit event) signal and the DMA controller shall transfer the data from source buffer to SPIDAT0/SPIDAT1 register in order to avoid CPU overhead to handle the SPI data transfer.

First, you need to set the ENABLE field of SPIGCR1 register to 1 to activate SPI transfer. Then DMAREQEN field of SPIINT0 register should be set to 1 to enable DMA request to be generated for transmit channels.

You have to use SPIDAT1 which is a data transmit and format select register and have an option to choose on which format, the data needs to be provided. You can do this by configuring the DFSEL bit in the SPI transmit data register (SPIDAT1) and select the appropriate SPI data format register n (SPIFMTn) but in slave mode, only SPIFMT0 is supported. You can also configure the format options like SPI data rate, character length etc. using the selected SPIFMTn. Please refer Section 30.3.13 in the OMAPL138 TRM as below:

http://www.ti.com/lit/spruh77

You have choice to decide the SPI data word length and can configure CHARLEN field of SPIFMTn register from 0 to 1Fh but legal values are 2h (2 bits) to 10h (16bits) and illegal values are 0 or 1Fh. By this, you have chance for the EDMA controller to split into 16bit and 8bit word length and transfer them to SPI interface without CPU intevention. Please refer Table 30-26 in the TRM above for the details given here.

I hope, it clarifies your query.

Thanks & regards,

Sivaraj K

Hi Sivaraj K,

Do you know if the EDMA3 controller take care about the "filling status" of the SPIDAT1 or SPIDAT0 register? I set up a AB synchronized transfer from a buffer  to SPIDAT1. The datas needs to be only transfered to the SPIDAT1 register. There are 2 EDMA transfers needed to get the 24 Bit out on SPI. When the JTAG debugger is connected an i step throug the code, after i set manually the DMA event, i get out the datas as expected. The 1st transfer includes the first 8 bit of the 24 bit data word and the second one the last 16 bit. immediately after disconnecting the debugger, i get out only the 16 bit part. It seems to me, the EDMA3 controller doesn't take care about a not empty transfer shift register.

Can you confirm that? Is there any workaround to handle this issue?

Thanks,
Christian 

Hi,

I got it almost. It seems the EDMA3 controller takes care about the status of the SPI TX register. the new datas are copied after the first ones shifted out. The important thing is, to give the EDMA3 controller enough time to transfer the datas befor start a new event. I tested it first only in a while loop and got really curious stuff out on the SPI interface. 

But now I have another problem :( The controll transfers only at the first event the datas from the buffer to the SPIDAT1 register and in the Most cases there happens an addition by 1 in the datas which are transfered. The 2nd and all following events transfers maybe datas, but not to the SPIDAT1 register. The datas there are still the same. The TCC seems to asserted back to the CC correctly, the bit in the IPR is always set after an event occurs. I also set all destination indexes in the PaRAM-set to 0. If I understood the Datasheets correct, when all Indexes set to 0, the address will not changed by the CC or TC.

Please find attached a picture of my debugging screen. You can see on it the Memory of the Buffer, where the datas to the SPIDAT1 register are stored and the corresponding IPR bit field to the transfered TCC=0x00000 and the registervalue of SPIDAT1. This picture was taken after the event was set manually by setting the corresponding bit (Bit19) in ESR.

I also attached the settings of the used PaRAM-Set19.

8321.PaRAM-Set19.pdf

I don't know where the mistake of mine could be. Hopefully you can help me.
Thanks,

Christian

Hi Christian,

I have reviewed the PARAM settings attached by you. It looks fine to me but to address your questions, please find the clarifications below:

1. As per datasheet, if SRCBIDX/DSTBIDX = 0000h, there is no address offset from the beginning of an array to the beginning of the next array. All arrays are fixed to the same beginning address. Likewise, it should be similar for SRCCIDX/DSTCIDX and in C index (SRC/DST), the current array is the first array in the frame for AB-Syncronized transfer.

2. Please ensure if your SRC and DST channel addressing mode are in increment mode, else if it is in constant addressing mode, you should program the destination address to be aligned to a 256-bit aligned address. In case of violation, EDMA3 TC will signal an error (Refer 18.2.3.2.3 & 18.2.3.2.4 in the OMAPL138 TRM

http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf

3. We should not use BCNT Reload (BCNTRLD) for AB-synchronized transfer.

4. If a transfer request is read from the PARAM set and in the process of submitting the request to EDMA TC, the following fields would be updated in case of AB-Synchronized transfer and will not be updated during linking where all fields will be overwritten by the link PARAM Set. Basically, PARAM update information is needed only when you submit the next transfer request to the transfer controller. No updates will occur when OPT.STATIC == 1 for any current PaRAM set.

I suggest you to check the mapping between PARAM set and its corresponding DMA channel. You need to program the PaRAM set for configuring transfers associated with corresponding event number, for example, in order to program a transfer for event number 2, DMA channel 2 should be associated with PaRAM set number 2. (Please refer Section 18.2.6.1 in the above TRM)

Thanks & regards,
Sivaraj K