Having problems with the virtual serial port

[Simon]

So, I'm new to LUFA so I may be missing the obvious here (I kinda hope
I am :) but was hoping someone might have some insight into why I
can't get the virtual serial demo to work...

I have a self-built board, and I've tested the mega16U2 on it without
running LUFA and it blinks the proverbial LED. So far so good. Also on
the board there's an tiny-87, which has its UART TX pin connected (via
an isolator, but that's not really relevant) to the RX pin on the
mega16U2. The Tiny is currently programmed to send an infinite series
of '*' (0x2A) characters separated by 100ms

When I build the virtual serial port demo, I can see the mega16U2
enumerate as a known device on the Mac (it appears as /dev/
tty.usbmodem5d11). You can see the enumeration at:

http://0x0000ff.com/imgs/lufa-enumerate.jpg

... and it also enumerates as /dev/ttyACM0 on a linux box I tried.
Unfortunately, if I run (on either MacOS or Linux):

[atlantis:~] simon% minicom -b 19200 -D /dev/tty.usbmodem5d11

... I see nothing - no star chars, nothing at all. I've verified that
the mega16U2 is getting star characters on its RX pin using a scope -
you can see the reading at:

http://0x0000ff.com/imgs/lufa-stars.jpg

... The transmitted bits are {0,0,1,0,1,0,1,0,0} which in 8-N-1
corresponds to 0x2A, which is the star character. The scope happily
picks up on this after a half-second of auto-tune, and although the
signal is deteriorated slightly by the galvanic isolation between the
tiny-87 and the mega16U2, it still looks perfectly reasonable.

What I was hoping was that I'd just be able to configure LUFA for the
chip I have (there's nothing else on the board I want to expose via
USB), connect up the terminal app, and see stars :) Presumably I'm
missing some (important) step along the way.

In the Makefile, I set the following (changed items prefixed by a
'*'):

* MCU = atmega16u2
ARCH = AVR8
BOARD = USBKEY
* F_CPU = 16000000
F_USB = $(F_CPU)

I've read that the board can be important - is there something I'd
need to do there ?

Any help gratefully received :)

Cheers
Simon

[sebion]

Hi Simon,

I don't have the code of the original virtualserial demo here, as I modified it to my board and for some tests, but IIRC this demo doesn't read the controllers uart natively. If you want it to receive bytes per uart and send it via usb to the pc you will have to add code that does this. The naked demo is only a virtual serial port. So have you tested a send character call in its main loop? It should show you if the basic usb stuff is working flawless. If that works just add your code for your serial-usb bridge and it should work.

Afaik this demo is designed for a particular board and mcu, so it will output status data via leds at portpins. I suggest you remove that code if your board/mcu doesn't provide those leds, or did you already do that? I wonder if you wont get compiler errors without changing the code, but as I said I don't have the original code here and can just judge from what I remember.

best regards,

Sebastian

[Dean Camera]

Indeed, Sebastian is correct - the VirtualSerial demo is just that. If you want a pre-baked USB to Serial converter, there's one in the Projects/ subdirectory:

https://github.com/abcminiuser/lufa-lib/tree/master/trunk/Projects/USBtoSerial

Which acts as a buffered USB to Serial converter out the AVR's USART.

Cheers!
- Dean

[Simon]

On Saturday, July 28, 2012 1:16:08 PM UTC-7, Dean Camera wrote:

Indeed, Sebastian is correct - the VirtualSerial demo is just that. If you want a pre-baked USB to Serial converter, there's one in the Projects/ subdirectory:

https://github.com/abcminiuser/lufa-lib/tree/master/trunk/Projects/USBtoSerial

Which acts as a buffered USB to Serial converter out the AVR's USART.

Whoops - guilty of lack of precision over here ... I am in fact using the Projects/USBtoSerial code, not the Demo one. 

[atlantis:LUFA-120730-BETA/Projects/USBtoSerial] simon%  ls

Config Descriptors.o USBtoSerial.c USBtoSerial.h USBtoSerial.o

Descriptors.c Documentation USBtoSerial.d USBtoSerial.hex USBtoSerial.sym

Descriptors.d Doxygen.conf USBtoSerial.eep USBtoSerial.lss USBtoSerial.txt

Descriptors.h LUFA USBtoSerial.inf USBtoSerial.elf USBtoSerial.map makefile

 

Although... it seems it's not LUFA that's causing the problems. I altered the RX interrupt code on the m16U2 to flash its own LED when it got a byte...

ISR(USART1_RX_vect, ISR_BLOCK)
{
led = (led == 1) ? 0 : 1;
PORTB &= 0xFE;
PORTB |= led;

uint8_t ReceivedByte = UDR1;
if (USB_DeviceState == DEVICE_STATE_Configured)
  RingBuffer_Insert(&USARTtoUSB_Buffer, ReceivedByte);
}

... and I see no flashing LED, even when I invoke minicom (which seems to be when the port is configured to use interrupts, in EVENT_CDC_Device_LineEncodingChanged(), yes ?). So something is interfering with the reception of the data, because I know that pin is receiving serial data. 

I have commented out all the LED_xxx calls, so they're not interfering with the program. Still confused, but I'll keep at it :)

Simon

[sebion]

That demo is designed for the at90usb1287 mcu, so I'd like to ask you if you are sure, that you changed the UART code to be compatible with your mcu? Does it have more than one uart and maybe you're using the wrong one? or maybe some register or register flag is mispelled. atmel likes to keep peripheral registers to be slightly different on different mcus... so thats where I would look for your issue first. Hope that helps.

Sebastian

[Simon]

Ok, one more update on this. It seems that EVENT_CDC_Device_LineEncodingChanged() is not being called (at least on the Mac. I haven't tried the Linux box yet). This presumably means that the interrupt is never being set up, which is why I wasn't seeing the led toggle previously.

I was just moving " PORTB |= 1;" statements around to see where the LED lit up. It lights up at the end of SetupHardware(), but not if I put the code into EVENT_CDC_Device_LineEncodingChanged  

Putting USART setup code into SetupHardware() gave me something at least. I now get a stream of 0xF8 chars. Not what I wanted, but still...

FWIW, the 'PORTB |=1;' line did light the LED in the following:

   void EVENT_USB_Device_ControlRequest(void)

   void EVENT_USB_Device_ConfigurationChanged(void) (and configSuccess returned true)

   void EVENT_USB_Device_Disconnect(void)

   void EVENT_USB_Device_Connect(void)

Simon.

   

[sebion]

so I just checked the at16U2's datasheet. The code for the uart seems to be compatible, so you don't have to change it. Another thing I would suggest you to further investigate is to check if the baud rate setting event gets fired (just put your led flash code in there). If it doesn't maybe you forgot to let your mac set it up?

regards,

Sebastian

[Sebastian Steppeler]

d'ouh! one minute late: D

I'm not experienced with the mac, but do you setup baud rate and etc. in you terminal programm when opening the connection? As there are pure virtual com ports this LineEncoding setup will not be done unless an application that uses the com port specifies a baud rate setting to use.

regards,

Sebastian

2012/7/29 Simon <krudtheb...@gmail.com>

   

--
You received this message because you are subscribed to the Google Groups "LUFA Library Support List" group.

To view this discussion on the web visit https://groups.google.com/d/msg/lufa-support/-/Rl1kXIwRK74J.

To post to this group, send email to lufa-s...@googlegroups.com.
To unsubscribe from this group, send email to lufa-support...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/lufa-support?hl=en.

[Simon]

Ok, that wasn't true :)

EVENT_CDC_Device_LineEncodingChanged() *is* being called when I open minicom or CuteCom on the Mac. 

Simon

[sebion]

but the uart interrupt is still not beeing fired? Is the baudrate / bitnumber / parity setting correct? if not the controller might refuse to accept the incomming data

[Simon]

Well, it should be correct. The tiny-87 is pushing out '*' characters at 19200, 8-N-1, with 100ms delays in between each. The Mac/Linux box is configured for 19200 8-N-1, and the m16U2 ought not care about its connection to the PC, right? That traffic always runs at USB-bus speed. Both tiny and m16U2 have their clock generated by (separate) external 16MHz crystals, which ought to be accurate enough at 19k2. I've checked that the CLKDIV8 fuse isn't set (even though Lufa turns it off anyway), and it doesn't look like its crashing anywhere (based on the LED coming on and staying on, no blinking as the chip resets or anything like that)

I've tried different terminal programs on different machines, the LED that indicates the m16U2 has received a byte refuses to blink, and the terminal program receives no characters. I know the tiny is sending the data because I can see it on the scope. I'm not sure what else I can configure.

The only time I've ever got any data out of it is when I configured the serial interface (wrongly, as it happens, I forgot to set the 8-bit-data bits) when I wold get a stream of 0xF8 characters. Apart from that, nada.

At this point I'm looking at the couple of bucks I saved by choosing an atmel-USB interface over using an FT232x and I'm thinking "hmmm".

[sigh]

Simon.

[Sebastian Steppeler]

Don't worry I'm sure together we will be able to make the demo work.

The m16U2 cares a lot about the pc connection, as that LineEncoding Event is fired only when your board is connected via usb. If that event is not fired your mcu will neither configure nor enable the uart or the receive interrupt and so your interrupt does not have any chance to get fired. The traffic between PC and m16U2 runs indeed with usb speed and there is no baudrate or anything else you have to worry about. the CLKDIV8 fuse can't be the problem, the clock frequency is correct, otherwise the device would not enumerate. So are you sure your uart gets configured? You could also try configuring it manually to see if there is everything correct with just the uart. In this case you should remove the uart code from that LineEncoding Event.

regards Sebi

2012/7/29 Simon <krudtheb...@gmail.com>

Well, it should be correct. The tiny-87 is pushing out '*' characters at 19200, 8-N-1, with 100ms delays in between each. The Mac/Linux box is configured for 19200 8-N-1, and the m16U2 ought not care about its connection to the PC, right? That traffic always runs at USB-bus speed. Both tiny and m16U2 have their clock generated by (separate) external 16MHz crystals, which ought to be accurate enough at 19k2. I've checked that the CLKDIV8 fuse isn't set (even though Lufa turns it off anyway), and it doesn't look like its crashing anywhere (based on the LED coming on and staying on, no blinking as the chip resets or anything like that).

 

I've tried different terminal programs on different machines, the LED that indicates the m16U2 has received a byte refuses to blink, and the terminal program receives no characters. I know the tiny is sending the data because I can see it on the scope. I'm not sure what else I can configure.

The only time I've ever got any data out of it is when I configured the serial interface (wrongly, as it happens, I forgot to set the 8-bit-data bits) when I wold get a stream of 0xF8 characters. Apart from that, nada.

At this point I'm looking at the couple of bucks I saved by choosing an atmel-USB interface over using an FT232x and I'm thinking "hmmm".

[sigh]

Simon.

--
You received this message because you are subscribed to the Google Groups "LUFA Library Support List" group.

To view this discussion on the web visit https://groups.google.com/d/msg/lufa-support/-/hTbokA2nI-EJ.

[Simon]

On Sunday, July 29, 2012 9:55:35 AM UTC-7, Sebastian Steppeler wrote:

Don't worry I'm sure together we will be able to make the demo work.

[grin] Thanks :) I'm very appreciative of your help, by the way :)

 

The m16U2 cares a lot about the pc connection, as that LineEncoding Event is fired only when your board is connected via usb. If that event is not fired your mcu will neither configure nor enable the uart or the receive interrupt and so your interrupt does not have any chance to get fired. The traffic between PC and m16U2 runs indeed with usb speed and there is no baudrate or anything else you have to worry about. the CLKDIV8 fuse can't be the problem, the clock frequency is correct, otherwise the device would not enumerate. So are you sure your uart gets configured? You could also try configuring it manually to see if there is everything correct with just the uart. In this case you should remove the uart code from that LineEncoding Event.

Well, it looks as though there's something else I need to sort out - SetupHardware() now looks like:

and the ISR looks like:

 

 ... so now I see the half-second illumination of the LED when we're in SetupHardware, but I'm still seeing no flashing LED for the receipt of any serial data. I #ifdef'd out the entire contents of EVENT_CDC_Device_LineEncodingChanged().

I can see that main() calls sei() just after calling SetupHardware(), so I'm not sure what else I need to do to get a serial port to work! I even tried hard-coding the UBRR1 value to 103 in case the macro wasn't working :)

Perhaps I just have a defective chip. It seems that serial ought to be easier than this!

Simon

[sebion]

I accidently sent this answer to Simon only, so I resend it here:

Okay then I have some other suggestions what you could do to encircle the issue:

- Have you tried rebuilding the project? I mean with a complete clean of all compiled stuff? I sometimes have issues with code that maybe not properly compiled because of whatever.
- Did you comment out the line in the makefile that specifies the usbkey board? It should have no effect, but just to be sure
- Your uart setup code looks fine to me, but just to be sure have you tried disabling the X2 option? also trying to setup a very small baudrate on both chips may help identifying the problem?
- Try to setup the uart for sending and probe with your scope, if it actually sends data and if the setup baudrate is met. If something is wrong with your controller hardware it might show up there as well
- Is everything correct with your power supply? I've had weird problems when using a cheap wall wart (i.e. I couldn't program the chip via ISP ). Did you place bypass capacitors at the chips power pins?
- How do you program the chip? USB bootloader(I think the interrupts in general should be working. otherwise enumeration of usb would fail)? ISP? If isp is connected while the application is running it can cause problems in rare cases depending on the programmer you use.

Thats all that comes to my mind for now, I hope it helps.

[Simon]

On Friday, August 3, 2012 3:00:08 AM UTC-7, sebion wrote:

I accidently sent this answer to Simon only, so I resend it here:

I'm glad you did :) because I didn't get the private message...  

Okay then I have some other suggestions what you could do to encircle the issue:

- Have you tried rebuilding the project? I mean with a complete clean of all compiled stuff? I sometimes have issues with code that maybe not properly compiled because of whatever.

yep, several times.

 

- Did you comment out the line in the makefile that specifies the usbkey board? It should have no effect, but just to be sure

I hadn't, but I just tried it and it made no difference.

 

- Your uart setup code looks fine to me, but just to be sure have you tried disabling the X2 option? also trying to setup a very small baudrate on both chips may help identifying the problem?

I've actually tried various baud rates - from low to high. Both AVR chips are running off 16MHz, so I even tried 250kHz because it has 0% error. Still no joy.

 

- Try to setup the uart for sending and probe with your scope, if it actually sends data and if the setup baudrate is met. If something is wrong with your controller hardware it might show up there as well

I haven't tried this yet (assuming you mean set up the USB AVR for sending - the tiny is definitely sending according to the scope.

 

- Is everything correct with your power supply? I've had weird problems when using a cheap wall wart (i.e. I couldn't program the chip via ISP ). Did you place bypass capacitors at the chips power pins?

Well, it's bus-powered, it reads 5v on the scope and everything seems to be working (the tiny, for example is happily sending off data, the bus-isolater in-between is powered up and happy. I would have thought the USB AVR would be ok too).

 

- How do you program the chip? USB bootloader(I think the interrupts in general should be working. otherwise enumeration of usb would fail)? ISP? If isp is connected while the application is running it can cause problems in rare cases depending on the programmer you use.

It's via ISP. I just disconnected the ISP jumper (good idea :) and removed/re-inserted the USB cable. Still no joy.

At this point, I think I'm going to go with the FT232RL - it ought to be a lot simpler than getting this AVR to work. I've a deadline, and this is taking too much time. I might come back to it afterwards, to satisfy my curiosity.

I *would* like to say a big thank you for all your help though - much appreciated.

Cheers 

   Simon