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.

USB Developer Package ported to mspgcc?

Other Parts Discussed in Thread: MSP430F5529, TEST, MSP430F5659, ENERGIA

I've looked around and didn't find any ports of the USB developer's package for msp430-gcc.  Anyone have any luck getting the USB code to work with gcc?  I took the simple C1_example and got it to compile, link and load however I'm not having any luck getting it to enumerate.  Any hints or suggestions would be appreciated. If I use CCS to compile and link the same code ( I made it CCS compatible ) it works fine.

-rick

  • BTW: I'm trying to get the usb developer package working with the msp430f5529 chip.

  • Just an idea: the problem might be linker related. The USB part and its USB ram need special handling. It's possible that buffers are moved to the 'wrong' ram, so things won't work.
    You should compare the map files of CCS and mspgcc for any obvious oddities.

  • Well I got it working. Turns out that gcc likes to align structures inside of stuctures on word boundaries.  The structures in desciptor.c that describe the USB device have an odd numbers of bytes.  The first one is 9 bytes long so the next structure gets padded with a 0 and starts on the next word boundary.  I changed the problem structures into a simple BYTE array and it just works. 

    -rick

  • So now that I have a working version of the simple USB example that works with msp430-gcc I'd like to share my changes to save others the hassle of getting it to work. However, looking at the license.txt that comes with the USB Developer's Package makes my head spin.  Has anyone decoded the legaleze and determined what can and can't be done with the USB stack code?  I'm guessing I can't share it as I had to login to my TI account and check boxes before I was allowed to download it.

    -rick

  • Rick Kimball said:
     The first one is 9 bytes long so the next structure gets padded with a 0 and starts on the next word boundary.

    GCC has a 'packed' attribute.

    If you apply it, no padding takes place, and the compiler does not generate word access isntructions to struct members (since the MSP cannot do misaligned word access - the LSB is always ignored). Basically, it then treats all elements as char arrays, just like you manually did.

    Older verisons of MSPGCC (V3.2.3 before 2008) didn't do this unoptimization on packed structs, resulting in misaligned accesses with desastrous results. This is why my own protocol structs are byte arrays too.
    However, the word access in padded and aligned structures is significantly smaller and faster, so this is the default and packed structures are the exception.

  • Rick Kimball said:
    Has anyone decoded the legaleze and determined what can and can't be done with the USB stack code?

    I guess, nobody has, except for the lawyers who wrote this stuff. 
    I always wondered why the legal text on demo code must be significantly larger than the code itself. Initially, I guessed that a certain minimum filesize might be required by the compiler, but this surely doesn't apply to a while USB stack...And even if, an exhaustive documentaiton of the code would be much mroe useful than legalese writings. (hey, isn't there a specific font available for legalese? One that makes all letters look like spaces?)

  • Jens-Michael Gross said:
     The first one is 9 bytes long so the next structure gets padded with a 0 and starts on the next word boundary.

    GCC has a 'packed' attribute.[/quote]

    I had actually tried the packed attribute. However, I only used it on the struct abromConfigurationDescriptorGroup.  I just created a small test program where I used it with all the structures abromConfigurationDescriptorGenric, abromConfigurationDescriptorCdc, etc... and that does works.  I assumed I would just have to put it on the group structure.  This is good to know as converting the structures to a BYTE array is kind of a pain.

    -rick

  • Rick Kimball said:
    converting the structures to a BYTE array is kind of a pain.

    I wrote a couple of macros that write or read a word/drword value to&from a byte array.
    It has the advantage that any little/big endian conversion is automaticly done when I use the same macros and structures on devices with different byte order.

    If you use the same structures with int or long int on two different machines, the values might be misinterpreted. With the macros and byte arrays, it is no problem usign the same definitions across different architectures.

  • Jens-Michael Gross said:
    I wrote a couple of macros that write or read a word/drword ...

    I would probably do the same thing if I were actually writing my own descriptors.  Unfortunately, the problem structures are coming from the TI USB Descriptor tool.

    -rick

  • Well, you can turn the reference of the element into a pointer to char and then use it as array of bytes in teh macro. Should be doable independent of the source of the struct.

    Something like

    #define readint(x) ( ((unsigned char *)(void*)(&x))[0]|(((unsigned char *)(void*)(&x))[1])<<8)

    (not tested)

  • Rick Kimball said:

    However, looking at the license.txt that comes with the USB Developer's Package makes my head spin.  Has anyone decoded the legaleze and determined what can and can't be done with the USB stack code?  I'm guessing I can't share it as I had to login to my TI account and check boxes before I was allowed to download it.

    From the 3.20 release notes:

    MSP430 USB Developers Package 3.20.00 Release (this release).

    • Updated to use BSD license.


    I just want to thank whoever took care of licensing the USB package. Thanks!

    -rick

     

  • Hello Rick,

     

    I'm trying to do exactly the same thing as you did : compiling the USB stack code of the 5529 with mspgcc, I'm using the experimenter board for now.

     

    I'm still not there yet and I have some questions for you :

    1) Which version of mspgcc are you using?

    2) In the dma.c file, I don't know what to use for the __DMA_ACCESS_REG__ #define

    3) In the usb.c file, with which statement do you replace the following :

    #pragma location = 0x2380

    __no_init tDEVICE_REQUEST __data16 tSetupPacket;

     

    Thanks in advance for your answer!

     

    Regards

    T.

  •  

    Rick Kimball said:
    ?  I'm guessing I can't share it as I had to login to my TI account and check boxes before I was allowed to download it.

    Now that usb descriptor tools has BSD'd is it possible for you to share your changes ? 

    best regards

    Santiago Barros

    PD: Using msp430f5659

  • You might look at the Energia implementation USB CDC device.  It uses msp430-gcc as the compiler.

    https://github.com/energia/Energia/tree/master/hardware/msp430/libraries/USBSerial

    -rick

  • i have tried everything and cannot get the usb examples to compile on mspgcc ... way too many issues .. can someone help?

  • Hello,

    Once I found this link but I haven't tested it : https://github.com/jlhonora/usb-mspgcc.

**Attention** This is a public forum