Serial Terminal Settings for Hello World Tutorial

General discussion about the Mojo
medios
Posts: 8
Joined: May 21st, 2013, 2:15 am

Serial Terminal Settings for Hello World Tutorial

Post by medios » May 21st, 2013, 2:22 am

So I am having one of days where I am blanking on the simple things. I have the Hello World tutorial bit file loaded onto the Mojo and I wanted to test it. I am have both the original Hyperterminal and RealTerm applications. The only problem is that I am getting myself mixed up on what settings to use to send the "h" and then recieve the hello world. Can anyone using either of those applications post the correct setting I need to have. Even if you don't use either of the applications I have mentioned, basic connection and translation settings would be greatly appreciated.

Thanks for this tutorial.....it was the missing piece I needed for my project!

leictreonaic
Posts: 23
Joined: April 24th, 2013, 12:17 am

Re: Serial Terminal Settings for Hello World Tutorial

Post by leictreonaic » May 21st, 2013, 11:29 pm

I just went through the serial tutorial and got it. I am running W7. !!Don't download Hyperterminal Private Edition!! The downloader I used added a bunch of spam programs from where I got it. Also it is only 30 day trial from download.com. Just use a free app like putty.exe.

Using putty change the connection type to Serial then choose the correct com port the mojo is on. I had to change mine from the default COM1 to COM3. Click open. Thats it. now just press the "h" key in the command line window and you should have it.
Last edited by leictreonaic on May 26th, 2013, 10:01 pm, edited 1 time in total.

embmicro
Site Admin
Posts: 834
Joined: March 24th, 2013, 12:45 pm

Re: Serial Terminal Settings for Hello World Tutorial

Post by embmicro » May 22nd, 2013, 11:31 pm

Since the Mojo isn't an actual USB->Serial converter (well actually, it kind of is but the AVR knows what the settings should be) the baud rate and other settings are ignored. I don' think handshaking settings will make any difference either but you can turn them off to be sure.

medios
Posts: 8
Joined: May 21st, 2013, 2:15 am

Re: Serial Terminal Settings for Hello World Tutorial

Post by medios » June 3rd, 2013, 9:08 pm

So I get the following using putty, is this an issue of my putty settings or the FPGA? If anyone can help I would appreciate it greatly!!
cropped bad hello world.png
cropped bad hello world.png (6.46 KiB) Viewed 9610 times

leictreonaic
Posts: 23
Joined: April 24th, 2013, 12:17 am

Re: Serial Terminal Settings for Hello World Tutorial

Post by leictreonaic » June 4th, 2013, 1:30 am

Try changing the Speed in putty to 500000. It looks like you have most of the characters there just not in the right place.

embmicro
Site Admin
Posts: 834
Joined: March 24th, 2013, 12:45 pm

Re: Serial Terminal Settings for Hello World Tutorial

Post by embmicro » June 4th, 2013, 3:48 pm

I'm not too familiar with putty, but can you list your settings?

Fucitol
Posts: 2
Joined: May 28th, 2013, 3:56 am

Re: Serial Terminal Settings for Hello World Tutorial

Post by Fucitol » June 8th, 2013, 1:18 pm

For me Putty worked using default serial settings, just connected to the correct COM port which resulted in a blank 'session' that responded correctly to the 'h'.

MacAttak
Posts: 72
Joined: April 28th, 2013, 1:27 am
Location: Atlanta, GA
Contact:

Re: Serial Terminal Settings for Hello World Tutorial

Post by MacAttak » July 7th, 2013, 4:45 pm

What is strange is that it worked properly using realterm at first. But at some point I must have accidentally clicked a setting in the realterm UI (and no idea what might have been clicked - the UI is horrible), and now I get the same output from the sample design as medios. And it isn't consistent... the output is different each time "h" is sent, but all responses are garbled. I've tried many possible settings and connection speeds from realterm - with no affect.

I'm not sure but it seems like something wacky happened on the pc side of the com port. Reconnecting the Mojo makes no difference.

I'll try it from a different machine shortly to see what happens there. Already tried from OS X, but for some reason as soon as OS X opens up the com port, the Mojo stops responding. The "done" led switches off and the port appears "in use" to any OS X applications until the mojo is physically reconnected.

embmicro
Site Admin
Posts: 834
Joined: March 24th, 2013, 12:45 pm

Re: Serial Terminal Settings for Hello World Tutorial

Post by embmicro » July 16th, 2013, 3:45 pm

There were a few bugs that got fixed in the AVR firmware and it's worth a shot to try and update your AVR first. Click here for update instructions.

MacAttak
Posts: 72
Joined: April 28th, 2013, 1:27 am
Location: Atlanta, GA
Contact:

Re: Serial Terminal Settings for Hello World Tutorial

Post by MacAttak » July 26th, 2013, 8:30 pm

I think there is some issues with the code for this tutorial that results in unstable results. Sometimes it works OK, but usually it sends garbled text to the serial port, and also seems prone to getting "stuck" in sending mode.

After trying to wrap my head around it, I wrote some testbench code to make sure that first the message_rom module and then the message_printer module were working properly. As far as simulation goes, they appear to work exactly as expected.

Building a testbench around the entire mojo_top to simulate sending the "h" trigger and decoding the serial_tx output is a bit too complex for me at this stage, and I'm betting the ISIM WebPack limits will probably make it unbearable to sim anyways.

So instead of simulating, I started using the LEDs for debugging. And here is where it gets weird. First, I added a switch to pin 121 using the button_conditioner module from a previous tutorial; this switch is used to put message_printer directly into PRINT_MESSAGE state. It makes it easier for testing because I don't need to use an external application to send the trigger "h" character. Next, since I noticed that the Mojo was frequently getting "stuck" sending garbled data, I decided to add an output wire to message_printer:

Code: Select all

assign sending = state_q == PRINT_MESSAGE;
And in mojo_top:

Code: Select all

assign led[6] = sending;
This is wired up to one of the LED indicators so I can see when the board is sending data (just to be sure that it wasn't my receiving app / serial console that was getting "stuck"). Sure enough - after a few triggers using my external switch, it would eventually get stuck with that LED lit... in other words, the state machine was getting stuck at PRINT_MESSAGE state. In looking more closely at the message_printer code, I see that the only way to go to IDLE from PRINT_MESSAGE is to click the RST button (which works) or tx_busy must not be high. Hmmm.

So next, I decided to see what happens with tx_busy when the design gets stuck sending data. I just added this to mojo_top:

Code: Select all

assign led[5] = tx_busy;
And sure enough, when it gets stuck sending data I can see that tx_busy is latched to a high signal. It stays high even if I press RESET button, which of course means that as soon as the next trigger is seen it will get stuck again. Once tx_busy is in this state it can only be recovered by power cycling the board.

So the bizarre output seems to be at least somewhat related to tx_busy being stuck high. But I'm at a loss to explain that - I don't understand why that would happen?

And to make it even more strange - when I have the 'tx_busy 'signal driving an LED the data that is received from the serial port is relatively clean. There are still occasional transmission errors that manifest as random character mutations in the output... but the error rate is low - under 5%. But when I'm not driving an LED with the 'tx_busy' signal the error rate goes up considerably - to something around 40%. And without the other LED watching the 'sending' signal (which is just comparing state_q to a constant), the error rate is really high... at least 60%... to where the output is barely intelligible.

I don't understand this behavior at all. Why would driving an output pin with an internal signal add any stability? Why would 'tx_busy' be getting latched high in the first place? And why would there be any errors in the data stream at all?

Post Reply