Getting STM32_USB-FS-Device_Lib_V3.1.0 to work with crossworks

Comments

32 comments

  • Avatar
    Andreas Falb

    Hi,
    I tried to start USB development too, but how did you get CrossStudio to recognize the STM32_USB-FS-Device_Driver?

    Andy

    0
    Comment actions Permalink
  • Avatar
    Paul Ellison

    Having great "fun" getting the STM32_USB-FS driver working. Are there actually ANY manufacturers that write Crossworks compatible examples?

    Really wanting to use Crossworks, but literally unable to get this USB project off the ground.

    0
    Comment actions Permalink
  • Avatar
    Paul Curtis

    Paul,

    The manufacturers are very good at getting GCC supported in their examples.  I know that Jon here had little trouble getting STM32 high-speed USB working with CrossWorks using ST's firmware libraries.  If you have a problem, raise a ticket...

    0
    Comment actions Permalink
  • Avatar
    Paul Ellison

    Thank you.

    0
    Comment actions Permalink
  • Avatar
    Gordon Scott

    I too am having more than a few problems at present with the STM USB Libraries (HS peripheral, but working only at full speed).

    Amongst other things, I'm finding registers used in the code that are not in the reference manual, and vice versa. There appears also a bug in the library that results in an IRQ hog.  I've asked some questions of STM and will post any useful answers.

     

    0
    Comment actions Permalink
  • Avatar
    Dreamsmatrix

    I have used the Roley port to the STM32-USB-FS library and have had a terrible time getting DFUSE working...It works with Keil and IAR out of the box...Here is my latest Complaint for Roley Crossworks. I have purchased two licenses from you (one commercial grade license for corporate use) and have fought hard in the company to keep using your product convincing them that you will come together and get better with time. I was sadly mistaken about this and let down! On the USB side, you have taken the easy way out, pushing out a useless USB template! No complete stack support? I have taken the Keil provided source and ported it with the appropriate flags and pre-processor directives...Upon code execution the device goes into suspended mode and tosses an Hard Fault...I cannot even get a correct call stack...Only Hard Fault pops up. I have tried Joseph Yiu method of reading the jump vector prior to fault and its pure garbage...Not an identifiable address to be seen. I have some old DFUSE firmware that by a wing and a prayer I got to work on the STM32L151 family. I tried to flash that into a STM32 L1 Discovery Kit and CRICKETS! Rowly does not support the internal ST-LINK/V2 firmware that is in that discovery kit. I would have to make a custom header just to run the SWD interface present on that kit!  have noticed lately, that there are no coherent projects being fully supported by Rowley, such as the USB Stack from ST. I am not sure why you are even trying to compete in that space with Keil and IAR. They provide a bit better support for the ST libraries for every example given. Does Rowley even test the USB stack ? I see people having a handful of similar problems as I am and nothing but compalints about the ST USB stack not being properly addressed by Rowley! I've just about had it up to here with the mediocre at best support and the missing functionality issues, not to mention the constant crashes even in the latest IDE...I do a search and I get a crash in Release 3.3.1.2014121602.22877. Even function searches in source cannot be properly located by your search algo. Even after the code is fully compiled? I know its a doggy dog world in the compiler business and Keil and IAR or ST could give a crap less about Rowley, perhaps they even want them to go away, but I am disappointed about the lazy approach by Rowley to give us functional examples. And my superiors are pushing me to switch to IAR and Keil now, saying that Rowley is not up to snuff...Sadly I will have to agree and perhaps as a toy compiler it does the job for some newbies and some simple standard library stuff. I just don't see it holding up in the ranks with the professional packages, especially in the USB arena, which is where professional development is done now a days. Full USB support is a must! Rowley must step up to the plate on this! Stop skimping around with one quarter of the way baked ideas that are not fully implemented and tested! I might consider giving them another try when the ST samples including HID and DFUSE are brought up to snuff with full Rowley compiler support and are not systematically being dumped on us as devs to wonder what we might have done wrong during porting from other compiler samples! Rowley should have full USB samples for all device families from the STM32F10x series all the L1 family...Otherwise, I hate to say this, but they are falling behind the times and I'm abut to throw in the towel after scrambling around with this poorly conceived compiler for about a year and a half...Sorry for the long rant! But it is well deserved and frustrating at the same time! 

    0
    Comment actions Permalink
  • Avatar
    Michael Johnson

    We only have a record of a personal license purchase from you - which commercial license are you referring to?

    0
    Comment actions Permalink
  • Avatar
    Dreamsmatrix

    I have a commercial license brought from Mouser...Regardless, I can submit you the serial tomorrow since I'm not sitting in front of my keyboard at work afterhours...I can tell you this much, that after my rant above, the same pompous attitude that you guys present on your forums, is going to cripple you in the eyes of customers in a very karmaic and systematic fashion...Consider this a lesson learned...When I bought the commercial license a year or so ago, we were a small multi-million dollar company...Now we are part of a multi-billion dollar conglomerate. We have IAR and Keil licensing available to us...It is unimportant which direction I am going, but because of the fact that you do not have a concept of customer loyalty and now this is turning into a tug-a-war over licensing issues in your mind, let me assure you I will not be wasting my time pushing through or recommending Crossworks from now on...A quick look on your site confirms my suspicions that  in fact you are pushing your own USB stacks and TCP/IP stacks and not doing a good job at supporting the ST Standard USB Libraries. I have not seen and indication nor heard a peep from you guys regarding the standard USB stack served open faced by ST...Not on the forums or anywhere. I know that ST has moved to and adopted the STMCube. You guys are doing similar copycat moves with FreeRTOS. However, sadly, there are other alternatives out there, some more expensive and some completely free. I cannot deliver a product for my client because of your deliberate disparity and lack of support on the USB Stack which should be public and publicly discussed. I will make sure to backtrack to Keil and Iar to get my job done for my clients, but this is a huge potential loss for what could have been an amicable discussion with a quick resolution. I'm done with Rowley! 

    0
    Comment actions Permalink
  • Avatar
    Michael Johnson

    Okay - I've seen a number of tickets that you submitted under this user id. I'll post all of these tickets to the user forum for the sake of balance.

    0
    Comment actions Permalink
  • Avatar
    Dreamsmatrix

    Michael, I am not interested in publicity...I have stayed up till 10:00 PM at work yesterday telling my project manager to give Rowley compiler another chance so that I can get the USB Stack working the way it works for FREE in KEIL and IAR with 35 K limitations of course...Believe me I'm not being vindictive here...I seriously took out of my day and spent many sleepless night prior trying to work through these mysterious issues that pop up with the USB DFUSE Stack, which I am promoting for a Clean Energy Product for my clients!  I have started from scratch today twice with this project by downloading your port! The jump from the NVIC Init call to Hardware_Fault is strange, because I see USB_Istr () getting pinged if I put a breakpoint in the ISR. No matter how much heap or stack I give it in Crossworks settings, it dies suddenly with no stack trace. It almost would seem like the NVIC is the issue if you judge via the Joseph Yiu method and do a trace on the last saved context prior to the Hard_Fault handler. To me it seems something is triggering that jump and that is a limitation you guys have put on the compiler so that we cannot run the free USB stack from ST! If that is the case and i hope it is not, you guys should know that it is not cool to proceed in this direction! I smell a no USB support on the license given even though it is a commercial license. Is this what is happening here ? If that is the case, we are not seeing eye to eye about this issue! Either way, I need this clarified if that is the case... Did you guys cripple the USB functionality of the compiler, Yes or No? Thanks, Mario

    0
    Comment actions Permalink
  • Avatar
    Michael Johnson

    I understand your frustration and accept we could do more - if you zip and attach your project I'll see if I can help.

    0
    Comment actions Permalink
  • Avatar
    Paul Curtis

    1.  We do not offer our own USB stack.  There is one internally, but we have not produced a product.

    2.  We do not cripple any examples, the compiler, the library.

    3.  Our USB stack would be licensed as a separate product tied to your product key.  This is how we license the mass storage and TCP/IP stack.

    4.  Seeing that you are not licensed for our USB product is correct -- you have not purchased our own USB product.

    5.  Jon had the USB port up and running pretty quickly on an F4.

    6.  ST and NXP, and TI for that matter, produce software that does not always work.  We report the problems to them.  They do a reasonable job of supporting GCC, but they don't do an excellent job.

    As a commercial license holder you have the option to call upon the ticketing system to try to resolve issues.  If you have no support because you've let it lapse, that's not much we can do about that, we can't force you to pay.  You are still entitled to download all the updates that we produce within a major version at no additional cost outside of SUA.

    We have a loyal set of customers, some of whom have never paid for an upgrade in the ten+ years that they have been using our product.  Clearly, we cannot serve every customer x every processor x every piece of software on the net.  It's just not possible.

    0
    Comment actions Permalink
  • Avatar
    Dreamsmatrix

    Paul, you are right...I have noticed a few weeks ago that my support has lapsed...I can assure you that you are right about the ST support. I see many notes out there from Clyde and others that know of certain issues with USB DFUSE not being reverse compatible. What's even more worisome is that my client has a new product with an older chip, the STM32F103R8 which I believe is still being produced by ST. We have option to go to FREESCALE. I refused to do so because I keep thinking I can handle it with the ST Standard Libraries, FREERTOS and so on. I am not the only engineer using ST parts. The company uses a variety of parts mostly ST and FREESCALE. Renesas has been knocking on our door lately. I have stayed very loyal to ST. This bootloader was my idea. I recommended it to my client. I am in shock that it does not work in Rowley. This has happened to me before one year ago with the L1 series. Same exact thing. It would work in IAR but not in Rowley Crossworks. I have found the compiler somewhat straightforward to use with minor annoyances, here and there. But mostly acceptable. I do not understand why so many issues with USB? They are clearly shown in discussions on forums. Very limited discussions, but nevertheless, very similar topic to what I'm experiencing. I have to move quickly! What do you suggest I do? Drop your compiler for the USB Bootloader use? Seems rather weird, no? What other alternative do I have? I am at a loss debugging this thing...I will try another older port of ST libraries, if I can find one somewhere...Otherwise, I'm stuck in limbo...I see no answers posted anywhere, so I am about to give up! :(

    0
    Comment actions Permalink
  • Avatar
    Dreamsmatrix

    Michael, out of courtesy, I will send you guys the zipped project. Where do I send it to? Do you have a google drive, or do I need to set one up?

    0
    Comment actions Permalink
  • Avatar
    Dreamsmatrix

    Paul, believe me, any support I get from Rowley it comes back two-fold into your pocket...This DFUSE bootloader being compiled, properly working and inserted into our product is a big plus and win win for you guys...I have until this weekend to get this going, so time is critical. This is my idea to use Rowley, the company does not care what I use, they just want the job done and customers happy! ;)

    0
    Comment actions Permalink
  • Avatar
    Michael Johnson

    Can you attach the zipped project to this discussion.

    0
    Comment actions Permalink
  • Avatar
    Gordon Scott

    I'm stepping in here for a few comments.

    First, I've always found Rowley to be remarkably helpful. They gave good support via the fora when I first started trying Crossworks and continue to give good support even though I'm overdue an upgrade. Hopefully I'll get that soon.

    As Paul says, the chip manufacturers' sample code is not always good (actually, read "usually rubbish").  It isn't really for Rowley, or indeed IAR, Keil, whomever, to fix ST/TI/NXP examples.

    I have had some problems in the past with the ARM interrupt priority arrangements, which was causing all kinds of interrupt conflicts and hangups. I've ended up always setting the priority system in one place as I think changes to it may cause problems in the the (STM32?) Cortex-M core. The following thread discusses lots.

    https://rowley.zendesk.com/entries/22037238-User-error-or-flaw-in-scheduler-

    Much of the code I use from ST has this in it:

        //=====================================================================
        //  DANGER..  See the notes marked in ###### in Drivers.h
        //=====================================================================
        // NVIC_PriorityGroupConfig(PE_PRIORITY_GROUP);    // already done elsewhere
        //---------------------------------------------------------------------

     

    And Drivers.h has this:


    //####################################################################
    // NVIC Setup Data
    //----------------------------------------------
    // CAUTION:    PM0056 is nonsense on this
    // See ARM's document DUI0552A_cortex_m3_dgug.pdf
    // Aaaaargh! That, too is nonsense as the parameters below don't match the documents!
    // (Or maybe just unclear).
    //----------------------------------------------
    //   This is what the compiled-help says:
    //    * NVIC_PriorityGroup_0: 0 bits for pre-emption priority 4 bits for subpriority
    //    * NVIC_PriorityGroup_1: 1 bits for pre-emption priority 3 bits for subpriority
    //    * NVIC_PriorityGroup_2: 2 bits for pre-emption priority 2 bits for subpriority
    //    * NVIC_PriorityGroup_3: 3 bits for pre-emption priority 1 bits for subpriority
    //    * NVIC_PriorityGroup_4: 4 bits for pre-emption priority 0 bits for subpriority
    //
    //  so let's try this...


    //
    // PriorityGroup_3 allows PreemptionPriority values only 0 through 7, but only 4 through 7
    // are masked by ctl_global_interupt_disable();
    //
    // This is all complicated because of 'virtual' decimal point in AIRCR.
    //
    //      CAUTION --  The following values are all interdependent, i.e.,
    //                  if PriorityGroup is changed, the meanings of the other
    //                  data also changes!
    //####################################################################
    //      This appears not documented properly in the manual or datasheet.
    //      The compiled-help manual for the StdPeripheralLibrary shows it.
    //
    //      In practice there are four bits available for priority grouping,
    //      which results in NVIC_PriorityGroup_3 having 3 bits for preemption
    //      priority and one bit for sub-priority.
    //
    //      OVER AND ABOVE THAT, ctl does not mask interrupts with the MSB set to 0,
    //      so will not disable interrupts at priority level 0..3.
    //      (which look in BASEPRI like 0x00 to 0x70).  Confusing, huh?
    //
    //    Putting that last bit another way, ctl's 'global' interrupt control
    //    will enable/disable only interrupts from BASEPRI 0x80 to 0x8F.
    //    Even with 'global' interrups disabled, BASEPRI interrupt values
    //    of 0x00 to 0x70 will _not_ be disabled.
    //      
    //--------------------------------------------------------------------
    #define PE_PRIORITY_GROUP                       NVIC_PriorityGroup_3    // 3:1 split
    //--------------------------------------------------------------------
    #define PE_PRIORITY_TTL_PREEMPTION_PRIORITY     4       /* the highest .. looks like 0x80 in IPRs */
    #define PE_PRIORITY_MOTOR_PREEMPTION_PRIORITY   5       /* looks like 0xA0 in IPRs */
    #define PE_PRIORITY_USART_PREEMPTION_PRIORITY   6       /* looks like 0xC0 in IPRs */
    #define PE_PRIORITY_USB_PREEMPTION_PRIORITY     6       /* ditto */
    #define PE_PRIORITY_SPI_PREEMPTION_PRIORITY     7       /* should look like 0xE0, but doesn't. Why? */
    //--------------------------------------------------------------------
    #define PE_PRIORITY_TTL_SUB_PRIORITY            0       /* no sub needed */
    #define PE_PRIORITY_MOTOR_SUB_PRIORITY          0       /* no sub needed */
    #define PE_PRIORITY_USART_SUB_PRIORITY          0       /* highest ( but it's quick )*/
    #define PE_PRIORITY_USB_SUB_PRIORITY            1       /* so 0xC0 becomes 0xC1 in IPRs */
    #define PE_PRIORITY_SPI_SUB_PRIORITY            0       /* no sub needed */

    There are also some oddities about IRQ enable/disable. Can't off-hand remember exactly what, but the thread disusses it.

    HTH

    Gordon.

      

    0
    Comment actions Permalink
  • Avatar
    Paul Curtis

    > the company does not care what I use, they just want the job done and customers happy! ;)

    ...then I'm pretty sure you have your answer already, no?  Asking for help on a tight timescale with no support is a tough call, should your neck be on the line.  You do what you know will work, and if you insist that IAR and Keil will "just work" then do the "just work" option.  Clearly we'd be sorry to lose you as a customer, but us promising to deliver something perfect to you in short order would not be in the best interests of anybody.

    As for delivering the project, you can create a ticket (which is private, not public), attach your code to it, and see where it gets you. We can delete the code / ticket when done, if you have concerns about your code hanging around.

    I would say that we report problems to ST, NXP, and TI, and others, and their response is usually nonexistent.  In the end, what's the point reporting problems each time?  When you report the same problem multiple times and each release of the software form the Si vendor has the same problem in, there's just no point in pressing the issue.  We do test the examples and, if you look at release notes for some processor BSPs, you will see that we know doesn't work.

    Either way, get the job done with what you know works as you're on a short timescale.

    I would add that I think the allegations you made are unfair -- CrossWorks is a complex product, as are the firmware libraries from manufacturers, and we don't say "Oh yes, all this cruft from the Si manufacturer, it just works..."  Most of it just doesn't.  They change things every bloody day, including renaming registers, getting SVD files wrong, the whole nine yards, and they're responsible for shovelling this shit out.  What response do you get if you knock on ST's door for an FAE, given they purport to support GCC?

    0
    Comment actions Permalink
  • Avatar
    Gordon Scott

    Company/client perceptions of USB don't help.

    I've had the comment "It's just USB; you plug it in and it just works; what's the problem?".

    The problem is that every time I bite my tongue, it hurts :-)

    0
    Comment actions Permalink
  • Avatar
    Dreamsmatrix

    Download the ST USB Stack + Rowley Crossworks Port from my google drive here :

    https://drive.google.com/open?id=0B6CMF1luccHMMjRCVlV1cm9fV0k&authuser=0

    Here is my Rowley ported DFUSE stack...Unrar everything and simply navigate to the directory : STM32_USB-FS-Device_Lib_V4.0.0\Project\STM3210B-EVAL.hzp. Maybe there is something dumb that I am doing. I thought I checked the ISR jumbs to match the jump table. It is hard for me to tell what is wrong. I don't see what is causing the hardware fault. No stack trace that I can see. After USB_Init() it crashes everytime. If I put a breakpoint in USB_Istr() I can see it looping there forever. If I take the breakpoint off, It suddenly jumps to Hardware_Fault. Keep me posted on what you guys might find...Cheers, Mario G

    0
    Comment actions Permalink
  • Avatar
    Michael Johnson

    Increasing the main stack size to 1024 seems to help here.

    0
    Comment actions Permalink
  • Avatar
    Michael Johnson

    Higher, higher - 2048 helps even more :->

    0
    Comment actions Permalink
  • Avatar
    Dreamsmatrix

    Just tried that and increased my heap to 1024 as well...So my stack is set to 2048! Unfortunately, I still see the device unrecognized USB Message pop-up and a jump to HardFault_Handler. Maybe our compilers are different, who knows? Pass me back the code you just ran! I am running on an STM32F103R8 and STM32F103RB for my tests... 

     

    /*******************************************************************************
    * Function Name : HardFault_Handler
    * Description : This function handles Hard Fault exception.
    * Input : None
    * Output : None
    * Return : None
    *******************************************************************************/
    void HardFault_Handler(void)
    {
    __asm volatile
    (
    " tst lr, #4 \n"
    " ite eq \n"
    " mrseq r0, msp \n"
    " mrsne r0, psp \n"
    " ldr r1, [r0, #24] \n"
    " ldr r2, handler2_address_const \n"
    " bx r2 \n"
    " handler2_address_const: .word hard_fault_handler_c \n"
    );

    while (1)
    {
    }

    }

    I have attached an image of the boards I'm testing with that I cannot get to work...And that will be followed by the Keil DFUSE that does work withing their constrains of 32K limit...

     

    0
    Comment actions Permalink
  • Avatar
    Michael Johnson

    I found that without the stacksize set to 2048 then when I plugged in the device it didn't get recognised. Do you get the device appearing in the device manager?

    0
    Comment actions Permalink
  • Avatar
    Dreamsmatrix

    Nope...Does not work! Not on a Windows 7 Host...I have tried every combination possible...

    0
    Comment actions Permalink
  • Avatar
    Michael Johnson

    Can you attach your .hzp file with the stack size property modification.

    0
    Comment actions Permalink
  • Avatar
    Gordon Scott

    FWIW, I've found different versions of Windows have different tolerances to the data in the enumeration messages. Some versions of Windows seem to need everything "Just as they like it", others will accept variations. In particular I had real problems with IADs, though you're likely not using them.

    STM's DFUSE also has a reputation for being non-standard and a bit "iffy".

    My Main and Process stacks are both 1024 (with a USB HS device) and seem stable, but if you have the RAM stick with the 2048 suggested by Michael. I may increase mine, too ... just in case.

    0
    Comment actions Permalink
  • Avatar
    Michael Johnson

    Probably not relevant - but looking through previous support requests I found this

     

    void USBD_GetString(uint8_t *desc, uint8_t *unicode, uint16_t *len)
    ......
    unicode[idx++] = *desc++;

    where idx is 56 and the unicode ptr starts off pointing at USBD_StrDesc

    USBD_GetString (USBD_PRODUCT_FS_STRING, USBD_StrDesc, length);

    where USBD_StrDesc is sized to be

    #define USB_MAX_STR_DESC_SIZ 50

    If I changed this to be 500 then a virtual COM port appears in the device manager.

    I'm not sure if this is the problem or not - can USB string descriptors be bigger than 50 characters?

    0
    Comment actions Permalink
  • Avatar
    Michael Johnson

    Are both stacks used?

    0
    Comment actions Permalink
  • Avatar
    Gordon Scott

    # Are both stacks used?

    Possibly not.  I had the RAM, I played safe.

    Much of my initialisation is done from main(), so possibly. Actrually, I really should check!

    # can USB string descriptors be bigger than 50 characters?

    I'm not sure, but if they're longer than that you'ld presumably need multiple packets to send it, which may well cause issues, vis my earlier comment --- Some versions of Windows seem to need everything "Just as they like it".

    Personally I would stick below 50 to avoid the risk.

     

    0
    Comment actions Permalink

Please sign in to leave a comment.