USBUART, v2.8 works, v3.0 doesn't ?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
user_108962310
Level 4
Level 4
10 likes received 10 likes given 5 likes given

I am trying to bring up some code on a PSoC5LP chip. I have an old project where I got the USBUART component set up and working, and I usually just copy & paste the component in, add the init code, and it works fine.

   

Recently, I updated the component in a design to the v3.0 version. Now, with the same init code and same hardware, the USBUART does not work, and hangs somewhere in initialization. If I copy and paste the old component, so I get the v2.8 one, then it works OK in the new project.

Here's a simplified version of the code I'm using:
 

   

char myStr[128];

   

int main()
{   
    CyGlobalIntEnable; /* Enable global interrupts. */

   

    /* Start USBFS Operation with 3V operation */
    USBUART_1_Start(0u, USBUART_1_3V_OPERATION);

   

     /* Host can send double SET_INTERFACE request. */
    if (0u != USBUART_1_IsConfigurationChanged())
    {
        /* Initialize IN endpoints when device is configured. */
        if (0u != USBUART_1_GetConfiguration())
        {
            /* Enumeration is done, enable OUT endpoint to receive data 
             * from host. */
            USBUART_1_CDC_Init();
        }
    }
    
    sprintf(myStr, "USBUART started.\r\n");
    USBUART_1_PutString(myStr);
    while( USBUART_1_CDCIsReady() != 0u );
    //LED indicated startup done
    board_LED_Write(1); //LED on after startup
    
    for(;;) {}

    return 0;

}

   

 

   

And ideas on what's wrong? I looked at the latest version of the USBUART code example project, and as far as I can tell, the init code is unchanged, and that is exactly what I am using there.

   

There was one strange issue with the driver, where Device Manager was reporting it as "Teensy USB Serial", but I forcefully changed the driver to the signed INF provided in the code example project, which loaded without a hitch. Device Manager now reports it as "Cypress USB UART".

0 Likes
1 Solution
lock attach
Attachments are accessible only for community members.
user_108962310
Level 4
Level 4
10 likes received 10 likes given 5 likes given

Well, as usual, Bob was right. Adding a busywait before the first USBUART write makes it work properly.

   

A minimum working example is attached. I hope whoever else stumbles upon this finds it helpful. The USBFS_UART code example is a little unhelpful, since it just echoes back individual characters. For dev board users like me, having the USB->UART working for general data export is great, now I can use this board as a very flexible interface to a bunch of sensors (all different interfaces) for which I am collecting data and characterizing.

View solution in original post

0 Likes
5 Replies
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

You are sending data to the USBUART even when it is not initialized correctly.

   

Can you please post a complete project, so that we all can have a look at all of your settings. To do so, use
Creator->File->Create Workspace Bundle (minimal)
and attach the resulting file.

   

 

   

Bob

0 Likes
lock attach
Attachments are accessible only for community members.
user_108962310
Level 4
Level 4
10 likes received 10 likes given 5 likes given

OK, so ... I can't quite reproduce this (I have the working version on my home computer...), so I have attached a version that doesn't seem to work at all.

The code to init the USBUART is taken right from the USBUART code example, as well as the PutString and block-until-complete loop. I am using the driver from the example project, which enumerates as "Cypress USB UART" in device manager.
Using the debugger (and the board LED), it does run through the initialization, but then opening a serial terminal yields no messages, and code waits on one of the while()'s when the USBUART buffer is full.

What am I doing wrong?

   

Having USBUART work is very important, it's the only way I can get data off the board. The usage here is interfacing to one I2C sensor, and to extend that to 10+ in the future. The BusPirate I was using was giving me spurious reads that I know are not correct, so I was just trying to hack together a simple sensor polling i2c-to-uart device.

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

(Without looking at it, wrong computer right now) Is your project still configured to use 3V, and your board too?

0 Likes
lock attach
Attachments are accessible only for community members.
user_108962310
Level 4
Level 4
10 likes received 10 likes given 5 likes given

Well, as usual, Bob was right. Adding a busywait before the first USBUART write makes it work properly.

   

A minimum working example is attached. I hope whoever else stumbles upon this finds it helpful. The USBFS_UART code example is a little unhelpful, since it just echoes back individual characters. For dev board users like me, having the USB->UART working for general data export is great, now I can use this board as a very flexible interface to a bunch of sensors (all different interfaces) for which I am collecting data and characterizing.

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

You making me flush!

   

Glad to have been of any assistance.

   

You were asking whether it is better to check USBUART_CDCIsReady() before or after an USBUART_PutString()

   

Comment in USBUART_cdc.cstates:

   

*  The USBUART_CDCIsReady() function should be called before
*  sending data with a new call to USBUART_PutString(), to be sure
*  that the previous data has finished sending. This function sends
*  zero-length packet automatically, if the length of the last packet, sent
*  by this API, is equal to Max Packet Size

 

   

This makes sense in so far that during some other jobs the string is sent in the background, giving a little bit more performance doing it this way.

   

 

   

Bob

0 Likes