MibSPI rx DMA

Ah, just had a thought..... is the DMA transfer initiated before the second byte has been read? Is it possible to only make a DMA request occur after a transfer group has completed?

Thanks,

Jack

OK, so setting BUFIDx to 1 (the last buffer used in the TG) fixed the problem, i.e. the DMA transfer was started before the second byte had been read in.  I would still be interested to learn the purpose of RXDMA_MAPx though!

Cheers,

Jack

Ah, understand the mapping now too!

Jack,

It seems that you already figured out the problem by yourself. Do you still expect an answer from TI? If not, would you please close this thread?

Thanks and regards,

Zhaohong

Hi Zhaohong,

I've figured out the previous problems, but I'm now struggling to configure SPI4.  I want to configure SPI4 in slave mode and read SPIBUF using DMA.  I have the DMA module configured and have turned on DMAREQEN.  When a new word is transferred to SPIBUF, it is correctly transferred to RAM.

However, it seems that data is only shifted into SPIBUF if SPIDAT1 is first written to.  I.e. I have to do the following:

while(1)
    spiREG4->DAT1 = ...

To force the SPI to read the next data word.  Obviously this isn't desirable!  If it don't do this, the SPI just stops shifting in data received from the master.  Is there a way to fix this?

Attached is my current code: 7444.test.zip

Thanks,

Jack

It also seems running in master mode (external clock) and in half duplex mode exhibits the same behaviour.

Jack

Hi Zhaohong,

Please take a look at section 24.2.17.2 of the RM48x technical reference manual.  This would suggest half duplex mode is available (rx-only in master mode).

So, is the only way to actually initiate a SPI read is to write to this register?

Thanks,

Jack

Jack,

In master mode, the SPI clock is started only after data is written into the transmit register (SPIDAT1 or SPIDAT0). In the slave mode, the SPI_ENA pin is in the ready state only after data is written into the transmit register (SPIDAT1 or SPIDAT0).

Thanks and regards,

Zhaohong

OK, so is there any way to automatically reset SPI_ENA in slave mode without writing to SPIDAT (and blocking the DMA controller in the process for a brief period)?

I will plough on using a DMA to write to SPIDAT (I have this working now), but it would be nice not to have to.

Thanks,

Jack

Jack,

I do no think that there are other options. Since it is a dummy write, you can set up DMA to move data from a fixed address in RAM to SPIDAT0/1.

Thanks and regards,

Zhaohong

OK, thanks.

I'm pretty close to getting everything working now (4 SPI channels of 5 running at 15Mbit/s each, DMA isn't quite keeping up with the 5th yet)... however, after fiddling with the HalCoGen file I'm now getting the error:

CortexR4: GEL Output: Memory Map Setup for Flash @ Address 0x0CortexR4: Loader: One or more sections of your program falls into a memory region that is not writable. These regions will not actually be written to the target. Check your linker configuration and/or memory map.
CortexR4: File Loader: Data verification failed at address 0x00000000 Please verify target memory and memory map.
CortexR4: GEL: File: C:\Documents and Settings\jwa\My Documents\Muddy Waters\test\Debug\test.out: a data verification error occurred, file load failed.

I reverted back to a previous version of the file but I'm still getting the same error.  Specifically, I restored test.dil and test.hcg.... are there any other halcogen files? Or is this error related to something else?

Also, in the clock settings of HalCoGen, it says the max PLL clock speed is 200MHz, but the RM48L952 datasheet says that the max clock speed is 220.  Is it OK to run it at 220?  I'm hoping the extra 20MHz will get my 5th channel working.

Thanks,

Jack

I've just created a completely empty project (including a new halcogen file) and am getting the same error.  Any ideas?

(I've updated to the latest version of CCS etc, but it still isn't working)

I've just tried this on a new computer with a fresh install of the toolchain and get the same error.  Could it be a hardware problem?

Thanks,

Jack

Jack,

I do not think it a hardware issue. Would you please send over the link command file and map file?

Thanks and regards,

Zhaohong

Hi Zhaohong,

Switching to a new board fixed the problem, so it seems to be a hardware problem.

Jack

Hi Jack,

Sorry for interrupting abruptly on this thread.

I am using HALCoGen and CCSv5.1 for TMS570LS3137 and getting the same error when I select Run>Debug in CCSv5.1

"CortexR4: GEL Output: Memory Map Setup for Flash @ Address 0x0CortexR4: Loader: One or more sections of your program falls into a memory region that is not writable. These regions will not actually be written to the target. Check your linker configuration and/or memory map.

CortexR4: File Loader: Data verification failed at address 0x00000000 Please verify target memory and memory map.
CortexR4: GEL: File: D:\UDAC\udac_v1\sci_PGE\Debug\sci_PGE.out: a data verification error occurred, file load failed."

I am attaching the cmd and map files please go through the files.6521.cmd_map.zip

I would like to have your comments on how can I obviate this problem.

Thanks.

Srikanta,

You need to check the CCS memory map configuration to make sure that Flash is set to address 0x0. When you load the code, you should see CCS message about the process such as 'flash is being erased".

Thanks and regards,

Zhaohong