TI E2E Community
Low Power RF & Wireless Connectivity
Low Power RF Bluetooth® Low Energy & ANT Forum
CC2540 USB problems
I am working with the CC2540DK-MINI kit but are having some problems with USB. We have created own hardware from the schematics from the USB dongle and when I flash the included "cc2540_ble1.0_master_usb_dongle.hex" the USB pops up on the PC and I can install the driver. But when I compile my own SW it only pops up as "USB Device Not Recognized". The same is the case if I flash the USB dongle with a sw I have compiled.
I have used the "SimpleBLEPeripheral" project and created a new group "CC2540USB" next to "CC2540EB" under HAL/Target and excluded the "CC2540EB" from the build. Then I have modified the include directories to match the USB target. When I compile this I get the following linker error:
Error[e27]: Entry "HalUARTRx::?relay" in module _hal_uart_usb (cc2540_ble\BLE-CC2540\Projects\ble\SimpleBLEPeripheral\CC2540DB\CC2540DK-MINI Keyfob Slave\Obj\_hal_uart_usb.r51 ) redefined in module hal_uart ( cc2540_ble\BLE-CC2540\Projects\ble\SimpleBLEPeripheral\CC2540DB\CC2540DK-MINI Keyfob Slave\Obj\hal_uart.r51 )
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.
WillisHave you initialized the UART interface
I'm having the same problem, did you find a solution?Regards,iR
In case anyone else comes across this problem my solution was simple. I had misread a filename and ended up including a source file twice in the project and hence the redefinition error.
So, to fix the problem, audit your project files to find the culprit. The quickest and smartest way to do this is to search (a simple ctrl+shift+f should do the trick) for the name of the entry given in the error message and, hopefully, the results will be from a single file and this have been included more than once in the project.
A little embarrassing... :) but I hope this helps.
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.
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.
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.
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.
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
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.
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:
However if I do the following, it won't work:
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 :(
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.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.