TMDX570LC43HDK: TMDX570LC43HDK

Hello Juergen,

There is a significant difference between the LS31xx and the LC43xx in that the LC43xx has Cache memory. What is likely happening is the data is being stored in cached copy instead of into the designated buffer. Can you try to change the Cache settings to write through and see if this resolves your issue?

Hi Chuck,

can you tell me how to? Is it a setting in Halcogen?

Regards,

Juergen

Hello We,

Can you please modify the code and do another test?
1. change the ma_tx_CTRLPKT.RDSIZE to ACCESS_16_BIT
2. change the destination address to (uint32)&(spiREG->DAT1)+2;

and also change the packet size to 16 bit for RX side.

Hi QJ,

I've tried all this different variants, no success. 8-Bit access should work, it worked on the R4 and I verified it on the R5-HDK by writing to spiREG->DAT1+3 with trough a 8-Bit pointer. I modified the example projekt a little, I found out it had absolute paths in the inlucdes - not used to CCS - sorry.

Somehow the DMA just doesn't write to spiREG->DAT1+3/2 even though the DMA interrupts are triggered.

Regards,

Juergen5635.DMA_SPI.zip

Hello We,

To setup a memory as write through, you would need to enable an MPU region for the buffer locations and select a type that includes write through. Hovering over the type field will provide the type definitions including if it is Write through or Write Back. More information on these modes can be found in the R5 TRM from ARM.

Hi Chuck,

I guess this sets the entire memory to "cache write-through".

It didn't help my problem with the DMA firing but not writing to the SPI-TX-Register. I guess something else is still wrong.

Regards,

Juergen

Hello We,

Above you mentioned that you originated this code/method on the R4 and R5 and it worked. Do you mean the RMxx devices? If so, these devices are LE so byte ordering might come into play if you are getting data from RAM in 8 bit increments.

Were you able to try the updates to the DMA packet size and destination address that QJ suggested? Especially the destination address change could be critical to the success of the write to the correct register.

Finally, you note that the write to the TXBUFF is not happening. How is this being verified? i.e., is simply due to not seeing output on the headers or is from reviewing the register content in CCS? Can you make sure that the S2 switch is set for SPI communications and not Ethernet? Also check to make sure there aren't any needs to configure the pin mux setting to bring SPI to the pins instead of another functionality.

Hello We,

Sorry I clicked the wrong button and marked it as "TI Thinks It's Answered" but this was an accident. Please ignore that.

I am curious if you can try starting the process by manually writing to the TXBUFF the first byte to transmit. I know this is the way the SCI works and in order to kick off the first TX, you have to do it manually then the DMA takes over.

Hi Chuch,

I don't think that's necessary, TRM says:

The first TX_DMA_REQ pulse is generated when either of the following is true:

• DMA REQ EN (SPIINT0[16]) is set to 1 while SPIEN (SPIGCR1[24]) is already 1.

• SPIEN (SPIGCR1[24]) is set to 1 while DMA REQ EN (SPIINT0[16]) is already 1.

This should be ensured by my code lines:

spiREG->GCR1 = (spiREG->GCR1 & 0xFEFFFFFFU) | 0x01000000U ; //enable SPI

spiREG->INT0 = (spiREG->INT0 & 0x0000FFFFU) | 0x00010000; //set DMAREQEN

I tried it either way, the result remains the same. SPI loops back in normal mode, DMA BTC interrupts are being fired. I think that means that the connection txBuf<--> DMA <--> SPI-TX-Register is set up wrong. I must be  missing a detail in the TRM/datasheet.

Regards,

Juergen

 

 

 

 

Hello Juergen,

I've asked QJ to have another look at this thread as well to see if there is something that he can spot that I am missing.