• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 30 subscribers
  • Views 419 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

CCS/TMDS570LS31HDK: SPI2 master to SPI4 slave : CS0, CLK, SIMO 3 wire connection externally not talking

CCS/TMDS570LS31HDK: _enable_interrupt_(); alters behaviour before it is executed.

Thomas Pikett
Intellectual 580 points
Part Number: TMDS570LS31HDK
Other Parts Discussed in Thread: HALCOGEN

Tool/software: Code Composer Studio

HALCogen 04.07.00

CCS 8.2.0.7

SPI2 writes 256 16bits to SPI4 as master to slave.

DMA set up on SPI4 with a frame count of 256 and element count of 1.5633.CAN_1_2.zip

I send 256 16 bits then set up RTI for 1ms and go into endless loop.

To get RTI to work I call _enable_interrupts_ from sys_core.h.

I added a long delay before the RTI initialisation. I put a breakpoint at rtiInit();

Without the line _enable_interrupts and stopping at rtiInit() the DMA is successful.

With the line _enable_interrupts and stopping at rtiInit() the DMA is not - or at least it shows zeroes.

This seems a weird kind of pre-emptive error. This is the end of the sys_main.c code:

for (k=0;k<100;k++) delay();

rtiInit();

rtiEnableNotification(1); // just enable Compare 0 notification

rtiStartCounter(0);

_enable_interrupt_(); // with this included even if the code is stopped at rtiInit() the

// DMA of data received on SPI4 shows nothing received. Removing this

// and stopping at the same place shows data DMA'd ok.

/* USER CODE END */

while(1);

}

  • 0
    Intellectual 580 points
    I've found a solution. I changed the DMA_Enable so that it ignores a suspend rather than stops.
    I did this after reading processor errata DMA#27.
    This in itself would not be expected to be the problem with the code/project I sent because of the delay I added.
    I guess the delay was not long enough or was optimized out so I was halting before the DMA completed.
  • 0 in reply to Thomas Pikett
    TI__Mastermind 21425 points
    Thanks for updating!

    Best regards,
    MIro
  • 0 in reply to Miro
    Intellectual 580 points

    My solution above was not a real solution. I now have a more specific problem. I am transmitting 52 * 16 bit data from SPI2 to SPI4 at 10Mbaud every 200us. Hardware triggered DMA on SPI4 transfers this data into RAM. The DMA request 24 (SPI4) is assigned to DMA request line 0.This all works fine with an RTI running at 100us. Also CAN1 writes to CAN2 in a one-off test  ok.

    Then I simply add a call to mibSPIinit() in sys_main  before spiInit()  and the DMA configuration. mibSPIinit() is set up by HALCogen to initialise a multibuffered mibSPI1.

    This stops the DMA working properly. Why?

  • 0 in reply to Thomas Pikett
    Intellectual 580 points

    I have the answer.

    spiDAT1_t dataconfig_tp;

    When declared as a pointer its address was set to 0. Unfortunately 0 is program memory not RAM.

    It was difficult to trace because the data at 0 was correct enough for the data in the structure to work.

    When the program size changed the values were not good enough, which explains the weird behaviour.

    At 0 is the code saying jump to cinit00 and cinit00 moved as the program size changed!

    How do I make pointers point to RAM without doing so when I declare them?

  • 0 in reply to Thomas Pikett
    Intellectual 580 points
    Silly me. The pointers are put in the first available location on RAM. They have to be initialised in code.