TMS320F28069: USB Serial Dev Example - Only See One Print - Then Nada

John Westmoreland43

Guru 13945 points

Part Number: TMS320F28069
Other Parts Discussed in Thread: C2000WARE

Hello TI(Sal),

OK - to continue on this thread:

I found in my app I have to do the following in usb_dev_serial.c :

In the:

// USBUARTRXIntHandler - Interrupt handler for the UART RX which is being
// redirected via USB.

__interrupt void USBUARTRXIntHandler(void) -

At the end of this IRQ handler I've had to put the following:

UARTIntClear(UART1_BASE, UARTIntStatus(UART1_BASE, false)); (I'm using UART1 vs. UART0.)

If I don't clear the IRQ's; the handler will not process any more messages; it'll just stop after getting the first message.

Note, I've tried looking at all of the status registers on SCI-B and USB0; and I can't find what the issue is here.

But, if I put that in; the IRQ handler at least keeps processing messages.

As a test, to make sure everything is working OK - I put the following in an 'idle' task:

uint8_t ui8Char;

ui8Char = 'A';
USBBufferWrite(&g_sTxBuffer, (uint8_t *)&ui8Char, 1);

A's were printed out on my usb/serial connection to the '69 USB I/F - so that works just fine.

But, I'm not sure why I had to call the UARTIntClear(); command to keep the IRQ running properly.

Any help appreciated.

Thanks,
John W.

over 7 years ago

0 Sal Pezzino over 7 years ago

TI__Mastermind 32995 points

Hi John,

I think your understanding is correct. You need to clear the interrupt status in the module as well as the PIE in order for another interrupt to be generated and propagated to the C28x.

UART1 should equate to SCI-A. You should be able to see the SCI RX or SCI TX interrupt status set on the SCI-A.

Hope this helps.

sal

0 John Westmoreland43 over 7 years ago in reply to Sal Pezzino

Guru 13945 points

Hello Sal,

For the TMS320F28069:

#define USB0_BASE 0x00004000 // USB 0 Controller

#define UART0_BASE 0x00007050 // SCI-A

#define UART1_BASE 0x00007750 // SCI-B

So, UART1_BASE points to SCI-B.

Is there a status register I can check before disabling the IRQ so I can see what's going on? - or should this be the normal operation, and if so, then

UARTIntClear(UART1_BASE, UARTIntStatus(UART1_BASE, false)); (I'm using UART1 vs. UART0.)

or the equivalent for UART0_BASE should be included in the examples that TI distributes.

Note for the transmission side - the device I have on the other end of SCI-B always returns the correct byte count, (it has a built in monitor facility), so at least that appears to be OK as is.

I also noticed something in the code for some of the newer processors, instead of using:

IntRegister(INT_SCIRXINTB, USBUARTRXIntHandler);
IntRegister(INT_SCITXINTB, USBUARTTXIntHandler);

the code uses:

UARTRXIntRegister(UART1_BASE, USBUARTRXIntHandler);
UARTTXIntRegister(UART1_BASE, USBUARTTXIntHandler);

does it matter or do these effectively do the same thing?

Thanks,

John W,

0 Sal Pezzino over 7 years ago in reply to John Westmoreland43

TI__Mastermind 32995 points

Hi John,

Sorry for the confusion. Usually the first instance is SCI A, but in this code, it has been mapped to SCI B. So you are correct.

The code is using SCI-B, and the interrupt status is in the FFTX register. The bit is TXFFINT. To clear it, write to the TXFFINTCLR. Does this answer your question?

Those functions for registering the ISR vectors should be doing the same thing. You can check the function definition and see the source code.

Regards,
sal

0 John Westmoreland43 over 7 years ago in reply to Sal Pezzino

Guru 13945 points

Sal,

I have the IRQ running a lot better now with this understanding; and I wrote a separate IRQ handler too for SCI-B just to do some testing.

I am getting a packet from a peripheral; it's around 1kB; I realize that unfortunately there's no DMA on this comm port (sci port) otherwise DMA'ing data I'm pretty sure would solve this issue that I'm seeing now I've gotten past the IRQ not working.

I think the data is getting to the SCI-B port fine; I have a BT radio I/F on SCI-A; and I'm echoing out data received on SCI-B to SCI-A as a check; (I
have an Android BT Serial port app on my cell and it gets the data packet just fine) once I go above 19.2kB, I'm seeing chars being dropped or distorted on the USB port output. I think the slowdown may be here:

USBBufferWrite(&g_sTxBuffer, (uint8_t *)&ui8Char, 1);

Is there any way to enhance the performance of this code?

If I run everything at 19.2kB it'll work; (the SCI-A to BT I/F is running at 115.2kB just fine - but I'm just echoing data right out of the SCI-A shift register).

So, any pointers on how to possibly speed up the transfer out of the USB port to virtual com port appreciated.

Thanks,
John

0 John Westmoreland43 over 7 years ago in reply to John Westmoreland43

Guru 13945 points

Sal,

In the usb lib code - I found the attached - the header of the usbcdc.h file says usbhid.h.

This is in the C2000 Ware 1.0.3 distribution.

Regards,

John

usbcdc.h

0 Sal Pezzino over 7 years ago in reply to John Westmoreland43

TI__Mastermind 32995 points

Hi John,

From the profiling I have done of USB communication on C2000 devices and Windows PC machines, I have noticed that the bottleneck for more throughput is actually the Windows PC sending DATA IN packets. The Windows OS as the master, must request data using via DATA IN packets. The slave (C2000) sends data in response to these DATA IN packets.

I am not sure how to easily increase the throughput by increasing the frequency of DATA IN packets being sent by PC. This may require Windows OS kernel programming and a kernel driver. We do not have support for this.

Using C2000 USB bulk devices with PC, I have achieved a max throughput of 7Mbps. This is due to the PC.

Hope this is helpful.

sal

0 John Westmoreland43 over 7 years ago in reply to Sal Pezzino

Guru 13945 points

Hello Sal,

I see C2000Ware_1_00_04_00 is released - and I still see what I posted about (above).

I use a lot of VCP stuff on this machine - I have some projects going at better than 1Mbps; so I don't think the PC here can be the issue; unless it's actually in the TI part of this code; which I suppose that's what you mean.

If it were possible to use VCP's with bulk-xfer; that would be ideal; but I know that is probably not even possible.

I did notice some notes in the docs about removing some error checking:
(P. 5 in Introduction:)

The capabilities and organization of the USB library functions are governed by the following design
goals:

They are written entirely in C.
They are easy to understand.
They are reasonably efficient in terms of memory and processor usage.
They are as self-contained as possible.
Where possible, computations that can be performed at compile time are done there instead
of at run time.

Some consequences of these design goals are:

To ensure ease of use and understandability, the USB functions are not necessarily as efficient
as they could be (from a code size and/or execution speed point of view).
The APIs have a means of removing all error checking code. Since the error checking is
usually only useful during initial program development, it can be removed to improve code size
and speed.

So, I'll look into this - removing some of the error checking and see if this can speed things up somewhat.

Thanks,
John

C2000™︎ microcontrollers

C2000 microcontrollers forum

TMS320F28069: USB Serial Dev Example - Only See One Print - Then Nada