Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Chuck

Pages: [1]
1
NXPTM M522XX, KINETIS and i.MX RT / Re: A USB problem
« on: February 08, 2010, 07:03:26 PM »
Mark,

Wow, you have been through long way, while I am away. Thank you for nicely fixing the problem.
Because I am running UARTs with hardware flow control, I just adopted the first fix to resolve the interrupt conflict.
It looks running OK so far. I will let you know, if the problem lingers.

Thanks again

Regards,

Chuck

2
NXPTM M522XX, KINETIS and i.MX RT / Re: A USB problem
« on: February 05, 2010, 11:20:25 PM »
Hi Mark,

I just ran uTasker demo program V1.4 on M52259 eval board and reproduced the problem in the following way.

Connect a USB cable, and open the corresponding virtual com port on a Hyper terminal (HT1).
Get the uTasker main menu.
Select 6 Go to USB menu.
Select usb-serial menu.

Connect a serial cable, open the port on another Hyper terminal (HT2).
Go to Hyperterminal menu Transfer/Send Text File...
Pick a long text file (~100Kb) and start sending.
The text displays on HT1.

Go to a web browser and open the uTasker home page running on the eval board.
Or hit the refresh button.

Once the web browser start loading, HT1 stops displaying.
I think this is the problem that I have.

Regards,
Chuck

3
NXPTM M522XX, KINETIS and i.MX RT / Re: A USB problem
« on: February 05, 2010, 06:52:26 PM »
Hi Mark,

I forgot to mention that I am using M52259 with uTasker V1.4 not V1.42.
There is no patch you mentioned in the version that I am using.
But, LAN_REPORT_ACTIVITY is not used, because LED indicators are connected to an external PHY.

Since you mention DMA, here is something unclear to me about DMA.
If two DMA's try to access the same memory block, does one have to wait until the other finishes or do they run perfectly in parallel?

If it is not perfect, can Ethernet DMA throw off USB transmission timing?

If USB stack send corrupted packet due to off-timing and  not get ACKed, can it retransmit the packet later, or the packet is lost and USB hangs?

I know there are too many ifs, but I don't know anything about two DMAs and USB retransmission, and I just get curious.. :-)
Thanks.

Chuck.

4
NXPTM M522XX, KINETIS and i.MX RT / A USB problem
« on: February 05, 2010, 12:32:25 AM »
Mark,

While doing USB stability test for my project, I have this subtle but very consistent problem.
I have a task that sends same size data (4 - 300 bytes depending on setting) to a PC through USB every 0.1 s.

It runs OK for days, if data size is small (probably < 64 byte) OR Ethernet is not connected.
When data size is bigger AND Ethernet is connected to the LAN, the USB communication hangs in a few hours.

It happens with no active Ehternet communication other than broadcasts from a switch.
There are UART communication is going on all the time, but it does not seem to cause any problem.

My guess is somehow Ethernet interrupts, taking place while the USB stack prepares the second or subsequent packets, may cause a problem.

How can I find a clue for this problem?

Chuck



5
NXPTM M522XX, KINETIS and i.MX RT / Re: How do I change hardware handshake lines in USB CDC?
« on: January 26, 2010, 08:26:25 PM »

Good news

It works! When I write 10 bytes SERIA_STATE notification into the interrupt IN endpoint, it sets DSR asserted in my application. According to a USB analyzer, the latency is less than 10 ms, as set in the interrupt endpoint description.

I send SERIAL_STATE notifications, depending on DTR state in Control Line State request sent by the host. It works like a charm.

I was worried how the Windows driver (usbser.sys) would handle the interrupt notification. Well, it handles DSR properly.


Bad news

With Codesourcery G++ lite complier, I was not able to make fnwrite into USBPortID_interrupt_3 work reliably. The USB analyzer shows notification is delivered sometimes OK, but sometimes no transmission or wrong string to the host.

I could not figure out what is wrong. I tried Codeworrior, and everything works fine.

I suspect something is not right with USB fnWrite if complied with the GNU complier.
My wild guess is it maybe be interrupt-related.

I also had problems in fnwrite into the data IN enpoint.
With continous sending data to the host, it crashes in hours. And it depends on the size of TxQueueSiz. The bigger queue size, the long it lasts before it stops.
At first I suspect the windows driver is faulty. But if complied with CodeWarrior, it works without problems.

I guess this is a issue you have to look into.

I always appreciate your dedication to uTasker.

Chuck

6
NXPTM M522XX, KINETIS and i.MX RT / Re: How do I change hardware handshake lines in USB CDC?
« on: January 18, 2010, 03:18:20 AM »
Hi Mark,

I don't think I clearly understand what has to be done for the interrupt. What I meant with interrupt PID was interrupt IN PID. If the interrupt endpoint has nothing to send when polled, it is supposed to respond with NAK. If not, I guess the host will wait until timeout. It is not clear that USB ISR sends NAK if the buffer is empty, since it is pretty complicated for me to read. Can I just write into the interrupt IN endpoint when a notification needs to send, otherwise the NAK is sent?

Chuck

 

7
NXPTM M522XX, KINETIS and i.MX RT / Re: How do I change hardware handshake lines in USB CDC?
« on: January 15, 2010, 02:30:19 AM »
Hi Mark,

You were right about the CTS line. It is not specified in CDC class. It does not seems changeable, without a customized driver. I hope at least I can control DSR line, because the program I want to use needs it.

Things are more complicated than I expected.
To send a notification to the host, the interrupt endpoint has to be activated.
When I looked in the USB interrupt sevice routine, static __interrupt__ void _usb_otg_isr(void),
I found that interrupt PID is not serviced and the endpoint is set stalled.

To add interrupt PID handler, I found I have to deal with low level USB  details that I am not familliar with. And then I can make it send SERIAL_STATE notification back to the host.
 
We will see if I can get 10 ms polling, if it is implemented.
Your help will be really appreciated.
 
Chuck

8
NXPTM M522XX, KINETIS and i.MX RT / Re: How do I change hardware handshake lines in USB CDC?
« on: January 06, 2010, 09:37:30 PM »
Your answer helps  a lot.

It looks like I have to implement a callback function for the interrupt endpoint to send a notification for SERIAL_STATE. Is it right? 

Thank you.

9
NXPTM M522XX, KINETIS and i.MX RT / How do I change hardware handshake lines in USB CDC?
« on: January 06, 2010, 12:42:52 AM »
Hi Mark,

I use USB CDC for serial communication emulation with 52259. It works great so far, and I want to have more control on hardware handshake lines for flow control. I can see how to update RTS and DTR lines from the host in control_callback function.

How can I send changes in CTS and DSR lines to the host? What do I write into USB_control end point?

Chuck


Pages: [1]