• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 41 subscribers
  • Views 637 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.

Pic32 cc3000 host driver porting STREAM_TO_UINT16_f issue

Shihab_T
Prodigy 110 points

I ported cc3000 host driver and basic wifi application for pic32 as per porting guide. I turned the cc3000 in smart config mode by typing 01 on console and LED2 started blinking. But it is not connected to network. On debugging i found that pic32 host driver receives 0x8080 HCI_EVNT_WLAN_UNSOL_SMART_CONFIG_DONE packet but  

STREAM_TO_UINT16(event_hdr, HCI_EVENT_OPCODE_OFFSET,event_type);  statement of function long hci_unsol_event_handler(char *event_hdr) in the event_handler.c is interpreting as 0x7F80.

when i tried this on msp430 5529 board this function correctly interpret as 0x8080. 

My understanding is that casting from signed char to unsigned short  is different in pic32 and msp430 especially when signed char is negative number such as 0x80.

I changed the function argument from
unsigned short STREAM_TO_UINT16_f(char* p, unsigned short offset)

to
unsigned short STREAM_TO_UINT16_f(unsigned char* p, unsigned short offset)

and smart config is done and my pic32 hostdriver is connected to network.

Anyone else experienced these type of issues?
Any comments from Ti?
This type of porting bugs may happens in any part of the cc3000 host driver code, am i right?

If i am on the right way, this post will be helpful to others.

Regards,
Shihab

 

  • 0
    Expert 2685 points

    Yes - I also had to rewrite these two functions because they were not compiling correctly in MSP430GCC, causing the memory that was being pointed to to be modified!

    Also it took me a while to understand what these two functions were supposed to do because of all this crazy casting there. I mean what is this, the International Obfuscated C Code Contest? I did not have to change the input parameter types though. Here is my code:

    // IVORS: WRONG - does not work properly with the MSP430GCC compiler in Eclipse
    //UINT16 STREAM_TO_UINT16_f(CHAR* p, UINT16 offset)
    //{
    //    return (UINT16)((UINT16)((UINT16)
    //        (*(p + offset + 1)) << 8) + (UINT16)(*(p + offset)));
    //}

    // FIXED VERSION
    UINT16 STREAM_TO_UINT16_f(CHAR* p, UINT16 offset)
    {
        p += offset;

        uint8_t n2 = *p;
        uint8_t n1 = *(p + 1);

        return (uint16_t)n1 << 8 | n2;
    }

    // IVORS: WRONG - does not work properly with the MSP430GCC compiler in Eclipse
    //UINT32 STREAM_TO_UINT32_f(CHAR* p, UINT16 offset)
    //{
    //    return (UINT32)((UINT32)((UINT32)
    //        (*(p + offset + 3)) << 24) + (UINT32)((UINT32)
    //        (*(p + offset + 2)) << 16) + (UINT32)((UINT32)
    //        (*(p + offset + 1)) << 8) + (UINT32)(*(p + offset)));
    //}

    // FIXED VERSION
    UINT32 STREAM_TO_UINT32_f(CHAR* p, UINT16 offset)
    {
        p += offset;

        uint8_t n4 = *p;
        uint8_t n3 = *(p + 1);
        uint8_t n2 = *(p + 2);
        uint8_t n1 = *(p + 3);

        return (uint32_t)n1 << 24 | (uint32_t)n2 << 16 | (uint32_t)n3 << 8 | n4;
    }

  • 0 in reply to Ivor Sargoytchev
    Prodigy 110 points

    Hi Ivor Sargoychev,

    Thanks for your comment. I want to know that is there any similar/dissimilar issues that must be taken care on using this host driver code. I found some suspicious while(1) statements which will surely cause cc3000 to hang in certain conditions.

    It will be very helpful if anyone can point out these situations.

    Thanks and Regards,
    Shihab 

  • 0 in reply to Shihab_T
    Expert 2685 points

    Yes, all while(1) loops in the code need to be handled properly. The biggest issue is the while(1) loop in hci_event_handler(...) in evnt_handler.c. This is where the MCU gets stuck when the CC3000 crashes due to the various firmware bugs. A timeout needs to be introduced here and the CC3000 restarted.

    There are a couple of while(1) loops in spi.c, when the RX or TX buffer are not large enough. Just look for CC3000_BUFFER_MAGIC_NUMBER in the code. Replacing these is a must.

    But there are so many other places in the code where the MCU can get stuck - maybe the best thing to do is implement a timer that monitors if it is stuck in loop and resets it.

  • 0 in reply to Ivor Sargoytchev
    Prodigy 60 points

    hi Shihab,

    I works too with Microchip, but i would like to know you have juste modifiyed CC3000 SPI to works with registers of PIC. that correct?

  • 0 in reply to marc labouille
    Prodigy 110 points

    Hi marc labouille,

    I just modified  modified CC3000 SPI file and executed basic wifi example code. CC3000 is then initialised successfully,but there was some issues on receiving some packet as described in the above post.after changing  the function argument from

    unsigned short STREAM_TO_UINT16_f(char* p, unsigned short offset)

    to
    unsigned short STREAM_TO_UINT16_f(unsigned char* p, unsigned short offset)

    in the file cc3000_common.c and cc3000_common.h

    Now it is working fine.

    Regards,

    Shihab