- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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".
Solved! Go to Solution.
- Labels:
-
PSoC 5LP
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
(Without looking at it, wrong computer right now) Is your project still configured to use 3V, and your board too?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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