CC2540 USB problems

Have you initialized the UART interface (it's actually a virtual UART, but the HAL initialization is the same). You can do that by adding this code to your application initialization function:

  // configure UART
  uartConfig.configured           = TRUE;
  uartConfig.baudRate             = HAL_UART_BR_115200;
  uartConfig.flowControl          = TRUE;
  uartConfig.flowControlThreshold = 48;
  uartConfig.rx.maxBufSize        = 128;
  uartConfig.tx.maxBufSize        = 128;
  uartConfig.idleTimeout          = 6;
  uartConfig.intEnable            = TRUE;
  uartConfig.callBackFunc         = myCBfunction;

  // start UART
  // Note: Assumes no issue opening UART port.
  (void)HalUARTOpen( HCI_UART_PORT, &uartConfig );

You will also need to define a callback function (in the example above it is called myCBfunction) of halUARTCBack_t.

Willis

Have you initialized the UART interface

Hi Christian,

I'm having the same problem, did you find a solution?

Regards,
iR 

Hi!
Regarding the callback function "myCBfunction". How can i do it?. I followed all the steps to configure the usb, but when connecting the pc does not recognize the device, what can it be?

For this project I relied on the SimpleBLEPeripheral, and I used the single-chip library.

thanks...

I also need help with these things... If someone successfuly uses USB with SimpleBLEPeripheral..

Maybe you could try excluding the _hal_uart_usb.c file from the project. When I did that, the error[e27] was gone!! It seems this problem could be solved by this way.

Yet I am working on CC2531 USB dongle, but not the one you did. So I am not sure if it will work for you. Another thing I am not sure is that if this setting would influence the functionality of the dongle. 

Hey all,

I found that to get this setup to work I needed to use ble_single_chip_slave_pm_off.lib rather than ble_single_chip_slave_pm_on.lib as BLESimplePeripheral does by default. Otherwise the device went into an infinite loop during LL_Init and eventually the USB host tired of waiting for the peripheral to be ready and gave a "USB device not recognized" error.

Chris

I have USB running well on simpleBLEperipheral using ble_single_chip_slave_pm_on.lib. It emulates an ftdi device and works with the driver.

Hi Eng,

Could you please tell me how to get that? I can get it to compile but shows up as unregognized device on my PC :(

Thanks a lot

Daniel

PS, I asked the same thing here because didn't read this post before.

I really can't get it working properly.

The only way I can get the virtual serial port working is by undefining POWER_SAVING and by calling HalUARTOpen in my init function.

However if I remove the initial call to HalUARTOpen and call it later in the code (pe, after a key press) it won't work. The workaround is to connect the pullup after a key press and it will work.

If I define POWER_SAVING, there's no way for me to make it work even though I call "osal_pwrmgr_device( PWRMGR_ALWAYS_ON );" before enabling the pullup.

I want to make a device which will be powered from a battery but when the USB is plugged it should enumerate a virtual com port to communicate with a PC but I can't get it to work and don't know if it's a limitation of the stack or I'm missing something.

BTW, I'm linking to CC2540_ble_single_chip_peri.lib and the base project is the SimpleBLEPeripheral.

Regards and many thanks in advance.

Daniel

Do you have a means of detecting USB connection and removal i.e. an I/O interrupt port?

On each connect your code should take the pull up high & call the USB init.

On each disconnect your code should take the pull up low.

Once the pull-up goes high that is signalling the PC that the device is ready for communication. If the init & process are not called quickly enough the PC will time out and show an error.

There should also be a de-bouncing timer so that the pullup and init does not fire repeatedly when plugging in.

As for the power management - have you checked in debug to see if your device is still going to sleep when USB is connected? osal_pwrmgr_device( PWRMGR_ALWAYS_ON ) should stop it going to sleep

Hi Eng, thanks!

It works if I do the following:

1. Call osal_pwrmgr_device( PWRMGR_ALWAYS_ON ) from the Init function
2. Launch a Timer from the init function
3. When the Timer expires, I take the pull-up high and call the USB Init function from the message processing function

However if I do the following, it won't work:

1. Launch a Timer from the init function
2. Call osal_pwrmgr_device( PWRMGR_ALWAYS_ON ) from the Init function
3. When the Timer expires, I take the pull-up high and call the USB Init function from the message processing function

I have tried to introduce several delays between points 2 and 3 in the second scenario but it won't work either.

This is what the Documentation says about the osal_pwrmgr_device:

This function is called on power- up or whenever the power requirements change (ex. Battery backed coordinator).  
This function sets the overall ON/OFF State of the device’s power manager.  This function should be called from a
central controlling entity (like ZDO).

I got no clue about what a central controlling entity or ZDO is but I guess that it might be failing because of calling that function when the timer expires?

As for the debugger thing, I'm using Windows Vista and it's a real pain to debug since it gets stalled over and over (not sure if it's a windows issue since it's my first time with the CC Debugger) and I can't follow the flow properly :(

Regards

Daniel

I also use vista & have no problems running the debugger. Have you tried it with compiler optimisation off and watchdog timer disabled? It is well worth it, it will make development much easier.

Have you examined the code behind osal_pwrmgr_device()? All it does is set a flag which gets examined inside osal_pwrmgr_powerconserve(). If it is set to PWRMGR_BATTERY osal_pwrmgr_device() will check if all tasks have finished processing and enter sleep mode if this is the case.

The two scenarios above should give the same outcome so I think something else is causing it to fail.

Why do you use a timer to trigger the USB init? osal_pwrmgr_device( ) sets the flag instantly so this will make no difference. 

Do you call the USB Event processing function in the main loop regularly enough?

Looks like I got it working now. The problem was that the HalUartInit function was called by the init function and that enabled the pullup so when I enabled it afterwards, nothing happened. 

However the debug process is not still smooth and I can't turn the optimizations off because I get the following error:

Error[e16]: Segment BLENV_ADDRESS_SPACE (size: 0x1000 align: 0) is too long for segment definition. At least 0x1000 more bytes needed. The problem occurred while processing the segment placement command 

"-Z(CODE)BLENV_ADDRESS_SPACE=_BLENV_ADDRESS_SPACE_START-_BLENV_ADDRESS_SPACE_END", where at the moment of placement the available memory ranges were "-none-"
Reserved ranges relevant to this placement:

Should I modify the linker script or that's because I ran out of memory? This project is a modification of the SimpleBLEPeripheral plus the USB uart stuff.

Regards!

Daniel