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.

TMS470M SPI Slave

Other Parts Discussed in Thread: TMS470MF06607, HALCOGEN

Hello

I'm currently trying to use a TMS470MF06607 as a SPI slave but am having problems with the TMS not responding to the SPI bus unless it has just been programmed.

While initially I saw the problem on a custom board, I have managed to recreated the problem using a Hercules TMS470M HDK with minimal changes to a basic HALCoGen project. In my HALCoGen project I have enabled only the RTI, HET and SPI1 drivers with each driver configured as:

RTI - Compare 0 period is set to 500ms. VIM channel 4 is enabled and set to ISR.

HET - Pins 0-5 set as output, odd pins set to output on their respective pins rather than read the even pins. 

SPI1 - Master mode and Internal Clock turned off

- SCS[0], SOMI, SIMO and CLK pins set to SPI, others set to GIO

- SOMI set to output

- SIMO, CLK and SCS[0] set to input

- Data Format 0 set to baudrate of 20000 kHz, Charlen of 8, Clock Phase set (Matching the SPI master device)

- Transfer Group 0 set to CS_0, buffer length of 1, TRG_ALWAYS, TRG_DISABLED, Oneshot

- VIM channels 15 (MIBSPI1 Level 0) and 16 (MIBSPI1 Level 1) enabled, connected to ISR

The PLL parameters have been changed to set give a Pll Freq of 100MHz, thus VCLK1 is 100MHz

Looks like: 

void main(void)
{
   int temp,delay=0x200000;
   hetInit();
   spiInit();
   rtiInit();

   rtiEnableNotification(rtiNOTIFICATION_COMPARE0);
   rtiStartCounter(0);
   
   spiEnableGroupNotification(spiREG1,0,1);
   
   spiSetData(spiREG1, 0, &spiRecData);
   spiTransfer(spiREG1, 0);

   while(1)
   {
      // Output number received over SPI to LEDs attached to HET[0..3] 
      hetREG1->DOUT &= ~(0xF);
      hetREG1->DOUT |= (0xF & spiRecData);

      // Match LED on HET4 to HET5
      hetREG1->DOUT &= ~(0x1 << 4);
      hetREG1->DOUT |= ((hetREG->DOUT & (0x1 << 5)) >> 1);

      // Simple Delay
      for(temp=0;temp<delay;temp++);
}

spiRecData is a static uint16 defined in the top user code section of sys_main.c.

The following Notification handlers are defined:

void rtiNotification(uint32 notification)
{
   if(notification == rtiNOTIFICATION_COMPARE0)
   {
      hetREG->DOUT ^= (0x1 << 5);
   }
}

void spiGroupNotification(spiBASE_t *spi, uint32 group)
{
   switch(group)
   {
   case 0:
      spiGetData(spi,0,&spiRecData);
      spiSetData(spi,0,&spiRecData);
      spiTransfer(spi, 0);
      break;
   default:
      break;
   }
}

This code will run fine if I program the device via CCS and disconnect the CCS debugger, the HET5 LED flashes due to the 500ms rti interrupt, the while loop in main matches it on the HET4 LED, and HET0-3 display the correct bit pattern for the number sent over SPI to the TMS470M (and the master can see the returned value as set in the spiGroupNotification handler).

The problem occurs when the board is power cycled, in this case I can see the interrupts are running and that the while loop in main is running by the LEDs on HET4 and HET5 flashing away, but the TMS never responds changes the LED patter on HET0 to HET3 or respond to the SPI master - has anyone run a TMS470M successfully as a SPI slave, or can point me to what is wrong?

Thanks

Mark 

  • I don't think the problem is the SPI slave mode because it works when you program and run from the debugger. Please check and verify that you are using "ROM autoinitialization model". It is specified in the project properties dialog box under CCS Build -> ARM Linker -> Advanced Options -> Runtime environment.
  • Hi Bob

    "ROM autoinitialization model" is selected

    Regards,

    Mark
  • If you reconnect the debugger after the power cycle and load symbols, but not reprogram the device, will the code still not work? If so, you can then debug why the slave SPI is not responding. I still think it is some initialization that is being done by the debugger that is not done when you run the code from flash.
  • Hi Bob,

    I'll give it a go in the morning (in the UK here). On the custom board I was able to detect that I hadn't had a SPI transfer in a while and dump out some of the MIBSPI registers over one of the sci ports (didn't see anything of note) - didn't think to reconnect without programming the device (doh!)

    Thanks for the suggestion!

    Mark
  • Hi Bob,

    Well, it's never simple! If I power cycle the board it starts and performs as described above (Interrupt / main loop running, no SPI slave functionality) - I then connect the CCS debugger with a "Load symbols only" configuration - it connects and halts the processor and shows me the current line of execution, with no break points set I just hit "Resume" - and the SPI slave functionality starts working!

    Regards,

    Mark

  • Hi Mark,
    OK, that is strange. I wonder if the debugger is reading a peripheral register which clears a flag or something that is keeping the SPI routine from running. Try closing any memory windows or watch expressions that point to peripherals before connecting to the device.
  • Hi Bob,

    All memory / dissasembly / watch windows closed in my debug perspective, no change to the observed behaviour, SPI slave starts functioning on connection via the debugger

    Regards,

    Mark

  • OK, my colleagues have an interesting theory. In the Technical Reference Manual SPNU495C, on page 1063 it talks about a specific behavior where if pulls are disabled (PULDIS=1) and the pull select is pull down ( PSL=0) the input buffer is disabled unless nTRST pin is high. The interesting part is that when you have JTAG connected nTRST is high. When JTAG is disconnected nTRST is pulled low.  Does your code disable the pull for the SPI pins? If so, make sure the pull direction is left to pull up. The TRM  only refers to this issue when the peripheral pins are used as GIO, but the same logic is used when the SPI pins are slave inputs. At least the theory matches the behavior you are seeing.

  • Hi Bob,

    I'm at home now so will play with the pullups in the morning - I know I did have (at least some of the lines) pulled up when first investigating the problem, but since the custom board has external pullups I disabled them to see if that was the problem (getting desperate by then!). Hopefully the direction is set to down and it is the issue, will let you know in the morning

    Regards,

    Mark

  • Hi Bob,

    That got it - now I'm going to swear that I left the pullups all turned on when I first noticed the problem, but obviously I could not have!
    Setting PSL to 1 for SIMO,CLK and SCS[0] on the SPI slave fixed the problem!

    Interestingly I hadn't noticed that the SPI master (another TMS470M) was exhibiting the same behaviour, it was not reading the returned data correctly (well, from this SPI slave, the test board has some other SPI devices on it, and the code was reading their device ID's correctly) - setting PSL for SOMI was not enough to make the return data function correctly, so I just set it for all the SPI pins (with PULDIS=1 for all of them), and everything appears to be functioning correctly now.

    Thanks to you and your colleagues for the help,

    Mark