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.

DM365 SPI1 - reliable communications with a MSP430?

Other Parts Discussed in Thread: MSP430F235

Howdy,

 

We have some errors on SPI1 with the DVSDK3 or DVSDK4 and Arago 2.6.32.17 kernel.  I see on these forums various solutions which work for some and not for others, on various kernels and devkits.

We've had limited success with SPI1 on our DM365 based custom board, by replacing the SPI0 init code with the SPI1 mux and irq's, since we only need SPI1 and not SPI0.  We're communicating between the DM365 master and a MSP430 slave, and the MSP430 is just running a simple echo RX->TX copy on its SPI IRQ handler.

Using the spi_test tool, we can see some of the data we send echoed back, but there are bitshift errors, and it is very dependent on initial conditions whether it works at all...

Multiple runs of the spi_test tool result in either garbled data, or a single-bit shifted data, or the correct data.  It can have correct data returned several times in a row, and then fail on the next send...  The speed seems to affect the results.  If I set the max_speed_hz to 1MHz, the data is always garbled.  The minimum 600KHz seems to give the best results, but still has errors.

Any ideas?

Here's a series of results:

 

./spitest

TX 

H  e  l  l  o     W  o  r  l  d    

48 65 6C 6C 6F 20 57 6F 72 6C 64 00 

RX 

  H  e  l  l  o     W  o  r  l  d  

00 48 65 6C 6C 6F 20 57 6F 72 6C 64 

./spitest

TX 

H  e  l  l  o     W  o  r  l  d    

48 65 6C 6C 6F 20 57 6F 72 6C 64 00 

RX 

  H  e  l  l  7    �          

00 48 65 6C 6C 37 00 0A E6 20 03 20 

./spitest

spi mode: 0

TX 

H  e  l  l  o     W  o  r  l  d    

48 65 6C 6C 6F 20 57 6F 72 6C 64 00 

RX 

     �  �  �  o     W  o  r  l  d  

00 20 94 D8 D8 6F 20 57 6F 72 6C 64 

changes done:

  1. removed check for SPI TX intr bit and SPI Buffer Init bit in davinci_spi.c
  2. substituted SPI1 for SPI0 in mux config, and resource ranges.
  3. arch/arm/mach-davinci changes to board-dm365 and dm365.c:

static struct spi_board_info dm365_evm_spi_info[] __initconst = {

  {

    .modalias = "spidev",

    .mode = SPI_MODE_0,  //one dev per bus |NO_CS

    .max_speed_hz = 700 * 1000,  //dm365 spi is 600khz-50mhz

    .bus_num = 0,

    .chip_select = 0,

  },    

};

 

static struct davinci_spi_platform_data dm365_spi0_pdata = {

  .version = SPI_VERSION_2,

  .num_chipselect = 2,

  .clk_internal = 1,

  .cs_hold = 1,

  .intr_level = 0,

  .poll_mode = 0, /* 0 -> interrupt mode 1-> polling mode */

  .use_dma = 0, /* when 1, value in poll_mode is ignored */

  .c2tdelay = 0,

  .t2cdelay = 0,

};

  • I see that the MSP430 SPI slave could be the issue, if it either

    1. doesn't keep up to the minimum clock rate of the DM365 master spi (600KHz).
    2. initializes its USCI module while the DM365 has some garbage data on clk/mosi lines before it finishes initialization.

    for point 1, what is the max rate that a MSP430F235 could support in slave mode?  The user's guide (SLAU144F) doesn't really mention slave timing restrictions.

    for point 2, how could I force proper synchronization of the MSP430 USCI module with the DM365's SPI module, when I only have SCLK/MOSI/MISO lines connected between them...  I can't reset the MSP430 or use the CS line as a signal.

     

    Regards,

    Mitch

  • Mitch,

    I found this post in the MSP430 Forum that sounds similar to yours: http://e2e.ti.com/support/microcontrollers/msp43016-bit_ultra-low_power_mcus/f/166/p/19004/73582.aspx#73582.  The problem in that case turned out to be a synchronization error between the devices.  Take a look and see it this helps move you forward.

    If the above post isn't useful to you, could you provide more information on how you have the MSP430 configured and how you start both devices up?

    Regards.

  • Mitch,

    Here's another post in MSP430 that discusses max SPI clock rate: http://e2e.ti.com/support/microcontrollers/msp43016-bit_ultra-low_power_mcus/f/166/p/19746/76921.aspx#76921

    It's not the same flavor of MSP430 as you are using, but should be similar.  Sounds like 600 KHz shouldn't be a problem.

    Regards.

  • Mitch -

    Agree that this is most likely a synchronization issue between the devices. Try the suggestions in the forum threads above and report back here on what you find out.  If this doesn't work we can look into it further, but I'm pretty confident that this will fix your problem.

  • Hi, we've tried various of the synchronization suggestions. 

     

    Currently issuing a USCI reset on the MSP430F235 after every data packet (of 32bytes), combined with a DM365  RS232 send inbetween SPI Master packet sends, in order for it our MSP430 to receive properly.  I imagine that SPI1 and RS232 share some SOC hardware functional blocks on the DM365?

     

    So our current (brittle) situation is:

    hack 1:  Reset MSP430 USCI after every packet.

    hack 2:  printf() to RS232 before sending every packet.

     

    Getting this far has been a challenge, and it is a brittle system.  What other synchronization options could be used?

    As a followup question, the MSP430F235 has no DMA functionality, so we have to service each byte on an IRQ.  This is quite a lot of IRQs, and the DM365 master has a MINIMUM rate of 600KHz SPI.  So when we transmit, we are generating 80KHz IRQs on the poor MSP430.  Is there a way to modify the DM365 SPI minimum rate below 600KHz?

    I calculate from MSP430F235 spec sheet that it can theoretically support a slave SPI frequency Fs=3.9MHz, but I cannot imagine this rate being serviced by an IRQ per byte.  (IRQ's on the MSP430F235 are documented as ~10 cycle latency minimum).

     

    Regards,

    Mitch

  • Hi Mitch -

    I agree that the poor MSP430 is probably getting a good pounding.  I'm going to cross post this thread over to the MSP430 forum since it looks like more of an MCU issue than a problem with the DM365.

    I will copy you on the thread so you can follow.

    John

  • Hi Mitch,

    can you test the lines of SPI with logic analyser or scope?
    You will be able to verify if there is everything correct on SPI or not.
    You can add some pin signaling (also recorded on LA) for illustration msp430 IRQ handler execution on msp430, just to verify that you have no overrun there.

    Sorry for naive question but are you sure that you have configured correct slopes for SPI?

    You wrote something about interferrences on SPI lines during configuration.
    Do you have Chip Select line to your external chip, you could keep it inactive while you are initializing.

    Regards,
    Piotr Romaniuk, Ph.D.
    ELESOFTROM

    PS
    What is a frequency oscillator of your msp430?

  • Hi Piotr,

    Thanks for the suggestions.


    We don't have a logic analyzer, but our 60MHz scope shows the SPI MOSI,SIMO,and CLK lines behaving acceptably and clean looking signals...  The logic low signal is below the DM365 3.3v input errata of 0.2V V.li  The SPI master is configured for 600KHz. 

    The DM365 master sends bursts of 8 bits at a time, with a wait inbetween bytes.  If we send larger bursts, the communication tends to break down entirely.  However, the SPI master frequency can be adjusted higher, all the way up to 15MHz or so before we see errors.  We are not doing much in USCIB0 interrupt handler, maybe one byte copy, and a couple of comparisons and integer increments.  This points me toward some sort of MSP430F235 limitation on handling the USCIB0 interrupt, or a serial peripheral misbehaving.

    I'm not sure what slopes are configurable, or where to do this.  I'm using the hardware SPI circuitry on both the DM365 and the MSP430F235, which do not mention any slope parameters related to SPI inputs in the user's guides.  The signals rise and fall very quickly on the scope.

    Our MSP430F235 is configured for max speed 16MHz.

    Regards,

    Mitch Rybczynski

     

  • Hi Mitch,

    I hope that your scope has more than one channel :)
    I advice to check time dependencies between signals on SPI and IRQ handler execution. In order to do this you need to add signaling code to your SPI IRQ handler. When you enter the handler please invert one bit in some output port. Observe a signal on this pin on scope together with SPI lines. After recording veryfy if all characters are received and processed on time.

    If overrun happens you will be able to catch it.

    Regards,
    Piotr Romaniuk, Ph.D.
    ELESOFTROM