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.

CC3100 Initialization

Other Parts Discussed in Thread: CC3100, CC3100BOOST

Hello,

I've ported the CC3100 SDK v0.5.2 driver to the Freescale Kinetis MK20. A few details about the setup:

  • MK20DX256VLL7
  • SPI interface
  • CC3100BOOST Rev 3.3
  • No RTOS

The clock polarity and phase are in mode 0. I have the nHib pin pulled up and wait until the IRQ line goes high. 75 uS later I set the CS low and start the first transmission from sl_WlanSetMode(ROLE_STA).

I see a 4 byte sync pattern (0x21 0x43 0x34 0x12) follow by another 4 byte sequence (opcode?) then a 24 byte sequence (payload?). The CS line goes high in between, but the datasheet indicated that was optional.  The issue is that I never see the IRQ line go low after the transmit finishes. Where should I be looking for issues? I've attached an oscilloscope trace. Line1-Data In Line2-CLK Line3-IRQ Line 4-CS

The wiki http://processors.wiki.ti.com/index.php/CC31xx_SPI_Host_Interface#Initialization_flow indicates a different sync sequence. Did I miss a flag when I set up user.h?

Thanks!

  • Hi Raleigh,

     

    We have identified a general issue with Freescale platform and CC3100. It seems that the SPI is stable only for a short duration.

    We are currently observing that on Freescale K60 platform but belive it can happen with any other Freescale.

    We are working to root cause the issue and identify a fix for that.

    Please bare with us until we will resolve it.

    More details will be provided soon.

     

    Best Regards,

    Nir Nitzani

  • Hello Nir,

    Thank you for your response. Is there a changelog or bugfix record to watch for this issue?

    Regards,

    Raleigh

  • Hi Raleigh,

    We are checking of what will be the right procedure of reporting/collecting known issue between service packs - we will notify once available.

    Regarding your porting effort - can you specify what is you SPI configuration? 

     

    BR,

    Nir Nitzani

  • I'm working on the same thing; with a Kinetis K10.

    I'll be happy to share my setup if I get it working.  For now I only read zeroes from cc3100 and it fails the sync test.

    Trying to verify my SPI setup, I see what I hope is a mistake in the data sheet, Table 4-8. Host SPI Interface Timing Parameters.

    It reads that the *maximum* clock low period and clock high period are 25 ns.  That needs to be in the other column to mean *minimum*, right?

    Roger

  • Another issue with the same table: TX data output delay has no unit - it looks like it should be ns.

    Back to subject, I don't see how timing should be my issue - I've got SPI going very slow so I can scope it. I will post my setup here in case that's not my problem and this setup actually is OK.  Keep in mind this is slow speed for scoping not production speed:

    // SCK baud rate = (fSYS/PBR) x [(1+DBR)/BR], DBR is 
    // Real slow for scoping: 20480k / 7 / 32 = 91.43 kHz
    #define SPI_CTAR_BR_VAL                 0b0101  // 32
    #define SPI_CTAR_PBR_VAL                0b11    // 7
    
    // Given delay prescaler 7 (b11) and scaler 64 (b0101) then delay is
    // 1 / 20480kHz * 7 * 64 = 21.9 us
    // Setting all the delays to this amount
    
    const uint32_t SPI_CTAR_VAL = 
            (
             //!SPI_CTAR_DBR_MASK |             // DBR 0
             //!SPI_CTAR_CPOL_MASK |            // Inactive state of clock low
             SPI_CTAR_CPHA_MASK |               // Data captured on following edge (falling)
             SPI_CTAR_PBR(SPI_CTAR_PBR_VAL) |   // Prescaler for rate baud rate
             SPI_CTAR_PCSSCK(0b11) |            // Prescaler between CS and CLK start
             SPI_CTAR_PASC(0b11) |              // Prescaler between CLK end and !CS
             SPI_CTAR_PDT(0b11) |               // Prescaler between !CS and next CS
             SPI_CTAR_CSSCK(0b0101) |           // Scaler between CS and CLK start
             SPI_CTAR_ASC(0b0101) |             // Scaler between CLK end and !CS
             SPI_CTAR_DT(0b0101) |              // Scaler between !CS and next CS
             SPI_CTAR_BR(SPI_CTAR_BR_VAL) |     // Scaler for baud rate
             SPI_CTAR_FMSZ(8-1));
    

    
    

    Roger

  • Here is a waveform of the first write and read.  It write 65 87 78 56 and then reads zeroes over and over until it gives up on getting a sync code and enters an assertion failure spin loop.

    Signals are EN (nHIB), IRQ, MOSI, MISO, CLK, CS.

    Any suggestions?

  • Fixed my problems with SPI by setting both these to zero in SPI_CTAR register:

    SPI_CTAR_CPOL_MASK

    SPI_CTAR_CPHA_MASK

    Hope this helps.

  • Roger,

    Thanks for sharing your solution. I've already checked the CPOL and CPHA are set to zero.

    My sync pattern is different from yours however. What wlan mode are you initializing to?

    Regards,

    Raleigh

  • Roger,

    Glad to see that the issue was solved 

    Raleigh,

    Are you using a sample code from the SDK?

    The first 4 bytes are not expected to be the 0x21 0x43 0x34 0x12 sequence. Is it possible that you called directly to sl_WlanSetMode API without calling sl_Start first?

    Barak

  • I was attempting to run the get-time example but I did not get that working.

    Tried a couple others and the only one that works successfully so far is the SPI debug example. So you might want to give that one a try.

    Roger

  • After researching another issue on another thread here I realized my main problem. My voltage regulator was not strong enough to power the K10 MCU and the CC3100BOOST at the same time. It is 0.5 amp. I added power by plugging the USB connector and changing the jumper and now everything works great.