66AK2G12: AB Sync mode between EDMA and SPI not functioning correctly

Hello,

I believe the issue is that you are not linking the next transfer. Please refer to section 10.3.5.7 "Linking Transfers" of the TRM. 

Regards,
Sahin

In our objective to get the interface between SPI and ADC working, we were trying couple of approaches.

We finally narrowed down on the following approach:

1. Configure PWM 4A to generate pulses at every 30 KHz. The PWM 4A pin is connected to CNV signal of the ADC.

2. On receiving the CNV signal from the processor, it sets the BUSY signal HIGH. After it completes the conversion in about 4µS, it sets the BUSY pin to LOW

3. The BUSY pin of the ADC is connected to GPIO1_44 which is configured as an input pin and triggered on the falling edge

4. GPIO1_44 is configured to generate EDMA synchronization event 60 on EDMA 1

5. The PaRAM set corresponding to event 60 is configured to do 1 byte transfer from 1 RAM location to another RAM location (Kind of dummy transfer not required for application. Dummy here does not mean that any of ACNT/BCNT/CCNT values are 0. It means a transfer of no use for application.) Details of the PaRAM set is as follows:

Table 1: PaRAM set corresponding to GPIO1_44

1. The PaRAM set corresponding to event 60 is linked to self-transfer, similar to Figure 10-13. Link-to-Self Transfer Example in TRM. The same is mentioned in the remarks corresponding to LINK in the above table

2. The PaRAM set corresponding to event 60 is configured with TCCCHEN=1 and TCC code of 4, corresponding to SPI2 XEVT. The idea is to chain trigger SPI2 XEVT, once the PaRAM set corresponding to GPIO1_44 is exhausted

3. The PaRAM set corresponding to event 4(SPI2 XEVT) is configured as follows:

Table 2: PaRAM set corresponding to SPI2 XEVT

1. The PaRAM set corresponding to SPI2 XEVT 4 is linked to self-transfer, similar to Figure 10-13. Link-to-Self Transfer Example in TRM. The same is mentioned in the remarks corresponding to LINK in the above table

2. In summary, when BUSY signal of ADC connected to GPIO1_44 goes LOW, it triggers the PaRAM set for GPIO1_44. On its completion, it chain triggers SPI2 XEVT the PaRAM set. The PaRAM sets of both GPIO1_44 and SPI2 XEVT are linked to self-transfer.

3. Additional note:

   1. The DMAREQEN is set to 1 in SPIINT0 register, once the PaRAM sets are configured and is the last step of SPI configuration/initialization

   2. We did not call the EDMA3_DRV_enableTransfer for SPI2 XEVT. By doing so the EER is not set for SPI2 XEVT

   3. Our observation is that if SPI2 XEVT is enabled and the PaRAM sets are configured for self-linking as mentioned above, then as soon as the code executes the line corresponding to making DMAREQEN=1, there is non-stop transfer of data on SPI2 MOSI/CLK lines

   4. Since as per Figure 10-5. EDMA Channel Controller Block Diagram, the synchronization event can be either event trigger OR Manual trigger OR chain trigger, keeping the event trigger disabled as mentioned in 3.b and chain trigger the SPPI2 XEVT as mentioned in step 2 aboove Table 1 should work. At least the oscilloscope image in Figure 1&2 confirm it

Observation:

To test quickly and keep our ADC board safe, we shorted the PWM4A pin to GPIO1_44 pin on the evmK2G board.

As shown in Figure 1, it is observed that at every falling edge of PWM4A, the GPIO1_44 PaRAM and SPI2 XEVTs are getting executed. However it is observed that for SPI2 PaRAM set, only 2 bytes (confirmed in Figure 2) are getting transferred as shown below. The yellow line corresponds to PWM4A output and pink line corresponds to SPI2 CLK

Figure 1:

Figure 2

To finally debug the issue, I did the following:

1. Disabled the TCCCHEN in the PaRAM set corresponding to GPIO1_44

2. Enable the event trigger for SPI2 XEVT

3. Disable the linking of PaRAM set corresponding to SPI2 XEVT. The idea was to capture one transfer. The same was shared in my original query

4. Kept the digital oscilloscope on single trigger on SPI 2 CLK line

5. Kept a breakpoint at the line where DMAREQEN of SPIINT0 is set to 1.

6. Single stepped at the line where DMAREQEN of SPIINT0 is set to 1 after the breakpoint in step 5 is hit.

7. Captured the oscilloscope screen as below. This again reconfirms that only 2 bytes are getting transferred. The logic analyzer also shows only 2 bytes of data.

    

Figure 3

1. Since it is confirmed that only 2 bytes are getting transferred, that too the 1^st and last byte, my original query still holds good. Is the PaRAM set configured correctly? Am I missing anything? Please confirm on urgent basis.