CC2540 - Max USB & UART HAL Ports

Aslak,

It sounds like YES you can use the USB and a single UART (w/ DMA) at the same time. Can you clarify how to add support for the UART peripheral directly.

Also whats the goal of copying the hal_uart_dma.c to two different files, are you trying to clone the singleton so you can use both UARTs? (Isn't there only one DMA...?) Or is that how is that how you go about adding the UART to the USB HAL.

Thanks for helping out with this.

Hi,

Yes, you can do that. There are more DMA channels, though. Channels 1 and 2 are used by LL encryption so BLE encryption can't be used if you use these for UART.

There is also a HAL UART driver based on ISR and not DMA.

If you want to use the UART directly, the easiest course of action is to look at the UART driver (either dma or isr) and also look at the USART chapter of the SWRU191 CC2540/41 User's Guide. Basically you just need to set up the hardware, set up the IO priorities if needed, select a baudrate and read/write to the UxDBUF register to transfer data. It's not that straightforward of course but the user guide explains the registers.

BR,
Aslak

Hi Aslak,

I'm a new user to the CC2540 and have been trying to figure out how to build a two port application similar to the topic in this thread.  I need one standard UART serial port and one USB port with our custom software in the middle as a message handler.  I have been searching everywhere for specific documentation on how to use the hal_uart_usb driver.  There's nothing in the HAL Driver API document, although it covers the standard UART case just fine.  Is there another document somewhere that covers USB API topics?

Thanks,

Steve

Hi,

I don't think it's documented to be honest. It's only used by one project, which is the HostTestApp, so you could look into the build configuration for USB.

You should find the files under HAL/Target/CC2540USB in IAR. It is, to my knowledge, used identically to the regular uart from an API perspective.

Using both at the same time is perhaps not as easy, but try adding the files for both UART and USB, and exclude the common hal_uart.c interface, which is designed to work with only one at a time. Then call the underlying interfaces directly yoruself (like you see it done in hal_uart.c)

Best regards,
Aslak

Thanks Aslak. Now I think I will have to use the HAL driver for the USB port and control the other UART directly because the the functions have the same names.

Hi,

I would like to follow-up on this question. We use the CC2540 in a couple of different configurations.  

The first configuration is the CC2540 USB dongle where we are using the USB interface for serial communications for our proprietary messages.  This was fairly straightforward with the definitions shown below. The USB based serial port operates at 115,200 baud. 

#define HAL_UART               TRUE

#define HAL_UART_DMA    0

#define HAL_UART_ISR      0

#define HAL_UART_USB    1

The CC2540 in the second configuration does not use the USB interface but the two UARTS are used to connect to two different devices for serial communication.  I was given to understand that only one of the UARTS can use the DMA engine while the other has to be ISR based. Based on this we use the following definitions and it works quite well for us, the port using DMA operating at 115,200 baud while the ISR port operates at 9,600 baud:

#define HAL_UART                TRUE

#define HAL_UART_DMA     2

#define HAL_UART_ISR       1

#define HAL_UART_USB      0

Now there is a requirement for a third configuration that uses the USB interface and one UART, both interfaces for serial communication, with the USB interface operating at 115,200 baud and the UART operating at 9,600 baud.  I tried the following settings:  

#define HAL_UART                TRUE

#define HAL_UART_DMA     0

#define HAL_UART_ISR       1

#define HAL_UART_USB      2

When I attempt this I get the following error in the compilation of hal_uart.c, "identifier HAL_UART_PRPIO is undefined".

I would appreciate your input in getting this third configuration to work.

I am using BLE Stack 1.4.0 with IAR EW for 8051.

Regards,

KK

Hi,

After experimenting some, I found that the following compiles for the third configuration mentioned above in my earlier post:

#define HAL_UART                TRUE

#define HAL_UART_DMA     1

#define HAL_UART_ISR       0

#define HAL_UART_USB      2

I ran the system using the above configuration and found I was able to communicate over the USB port at 115,200 without a problem and the host application at the other end of the USB port behaves exactly as I expected.  However, the UART port using DMA is running into some issues.  I am investigating this further and will reach out when I have answers.  But before I go much further down this path, I have further questions.

Earlier (a few months ago) the TI FAE clarified that when using two UARTs, only one can use DMA while the other has to be configured for ISR, as mentioned in the second configuration of my previous post (and this configuration works beautifully for our needs).  

I sort of implicitly believed that when a port is configured for USB serial communication it is using the DMA engine.  Is this true?  

If so, my configuration in this post could be invalid, since the UART is using the DMA engine.  Could you please clarify?

I would appreciate your input on this.

Regards,

KK

Hi KK,

As far as I can find, the USB CDC driver does not use the DMA engine. Can you give some details on the issues you are facing? Are you using an encrypted BLE connection at the same time? Which BLE SDK version are you using?

Best regards,
Aslak

Hi Aslak,

Thanks for the quick response.  I appreciate it.

We are not using an encrypted connection.  

We use BLE SDK 1.4.0.

It's a big help to know that the USB CDC driver does not impact our ability to have our UART connection use DMA for implementing a serial connection.  Since I have the UART+UART working well for our application, I just naturally assumed that USB+UART would work as is, but it does not.  I need to debug this a little bit more before I present the problem to you. BTW, in implementing the USB+UART configuration I find that it takes around 300 - 350 bytes more than the UART+UART implementation.

Thanks again for your response.  I will get back to you with questions or let you know if it all works.  

Regards,

KK

Hi KK,

It is still possible that there isn't enough CPU time to deal with a high throughput stream in both USB and UART, and so the UART DMA buffer may overflow for example. We haven't tested your setup that I am aware so it's only speculation.

BR,
Aslak

Hi Aslak,

In the case of my UART+UART configuration, one of the UARTs uses DMA and operates at 115,200 baud while the other UART uses ISR to operate at 9.600 baud.  This works without a problem for our application.

In the USB+UART configuration, the USB serial port operates at 115,200 and the UART operates at 9.600 baud.

If this is the case, do you believe CPU cycles are an issue for the USB+UART case but not a problem for the UART+UART.  In other words, is there significant overhead to using the USB CDC driver in conjunction with UART DMA driver versus UART DMA + UART ISR?

Regards,

KK

Hi,

No, not really. I was thinking of 2x 115200. 9600 is pretty slow relatively and with 1 stop + 1 start bit would only fill the buffer at 960 bytes per second ~133ms for 128 bytes.

I don't have numbers for the overhead for USB is unfortunately, or what your application does. The DMA buffer is normally only checked each time the osal loop runs, which is after some task is finished with the processEvent function.

Let me know when you have more information about how things fail.

BR,
Aslak

Hi Aslak,

I misspoke earlier when I said that in the USB+UART with UART using DMA that the USB port was working well.  The Tx of the USB going to the host works well and I see all the packets coming through on our host.  However, the Rx of the USB was not receiving anything from the host even though it's only a small trickle of traffic from the host to the CC2540 over USB but fairly critical to the operation of the system.  I poked through the USB driver in _hal_uart_usb.c and I noticed that when invoking the callback it always passes port 0 (HAL_PORT_0) rather than port 1 (HAL_PORT_1), which is what i was expecting (take a look at usbCB(0, evt) in _hal_uart_usb.c).  It looks like the drivers for a pure UART connection, i.e., _hal_uart_isr.c and _hal_uart_dma.c have been written properly to handle the right port when both UARTs are configured but not for a combination of _hal_uart_usb.c and _hal_uart_dma.c resulting from a USB+UART combo.

I converted my setup as follows, so that this configuration would correspond to the USB CB:

#define HAL_UART                TRUE
#define HAL_UART_DMA     2
#define HAL_UART_ISR       0
#define HAL_UART_USB     1

The above naturally aligns the configuration with the _hal_uart_usb.c driver and when the callback is invoked with port 0, it should pick up the right port. Well, this is what I expected.  Instead I find that the usb callback is never invoked for the USB port but instead it always invokes the DMA port's callback.  To clarify this, I specified the USB port's callback for the DMA port's callback and now I see that the CC2540 receives traffic that was sent from the host over the USB port.  This was just a temporary workaround to confirm my observations.

Is this behavior consistent with your expectations?

I am quite sure I am not the first person to request USB+UART functionality.  Has this problem been resolved before?  Any suggestions from your end to get this working?  I think I have to dive into these drivers and extricate the parts that are intertwined especially because hal_uart.c includes both source code files _hal_uart_usb.c and _hal_uart_dma.c.  

I would appreciate your input.

Regards,
KK

Hi KK,

We have not really designed or tested the HAL serial drivers for the CC254x series for your use-case, but only one active at a time. So in that sense yes, I would expect the possibility for mismatches with regards to the settings when combined unfortunately.

Again unfortunately, I am not aware of us in the support team assisting in combining these interfaces.

That being said - it seems you have come down to the crux of the issue, and you should feel free to modify any part of the drivers so they work in your situation.

The defines and callbacks and general architecture defined by the HAL drivers are not necessarily the best way to do things in all cases, but are mainly designed to support our sample applications and serve as examples themselves.

I would recommend you use the code in the drivers as a reference to how to utilize the hardware, and the software architecture as a reference to how it can be structured.

Best regards,
Aslak

Hi Aslak.

Thanks for your inputs.  I was hoping that TI would support this out of the box, since it is part of the CC2540.  

However, I was able to modify the USB drivers to handle the HAL_PORT properly and make it coexist with the UART drviers. The changes in themselves were relatively straightforward.  I wish it was part of the SDK, which otherwise is done well, especially since others in the forum have requested this feature.

Our application works quite well with the above changes that I made and both USB and UART function properly.

This matter is closed from my side.

Regards,
KK