system console, external memory, multiple masters

--- Quote Start ---

I suspected the baud rate and slowed it down from 115200 to 9600 baud. I changed this in both qsys and putty. I dont think i need to change this anywhere else, correct? the ftdi chip layer would be transparent, right? And, wouldnt need a specific rate.

--- Quote End ---

The FTDI device is a USB-to-UART, so when you change the baud rate in Putty that change is communicated to the FTDI device, and the baud rate is changed on the TXD/RXD signals to the FPGA.

I'm not sure why you changed the baud rate in Qsys. A UART should have control registers that set the baud rate, and so you would need to change the software that initializes the baud rate to set the baud rate divisors. But perhaps Qsys allows you to set the default divisor values. Either way, if there is are baud rate divisor registers, you need to make sure your software configures them correctly.

The quick-and-dirty test that you have the baud rate correct is to SignalTap II the UART TXD/RXD traces and trigger on the falling edge of either of those signals. Use Putty to send a character and trigger SignalTap II. Then use NIOS II to print "Hello World!" and trigger SignalTap II. If your bit timing is wrong, then you'll know your baud rate setup is wrong.

Cheers,

Dave

Hi Dave

I see the UART RX pin in signal tap, but not the TX pin in the node finder. Is there a way to manually enter the TX pin?

Also, would i just trigger on the RX pin or a nios variable using the nios plugin?

thanks

--- Quote Start ---

I see the UART RX pin in signal tap, but not the TX pin in the node finder. Is there a way to manually enter the TX pin?

--- Quote End ---

Its a top-level pin, so it should show up. Check the filter settings in the setup window where you add the signals to tap. I'm pretty sure there is a pins filter.

--- Quote Start ---

Also, would i just trigger on the RX pin or a nios variable using the nios plugin?

--- Quote End ---

Trigger on the falling-edge of the UART signal, i.e., the start bit.

Cheers,

Dave

Hey Dave

So i spent the rest of the day trying to get signal tap to work. i managed to get it to compile a couple times, but most of the time quartus just errored out with this:

Problem Details
Error:
Internal Error: Sub-system: VPR20KMAIN, File: /quartus/fitter/vpr20k/quartus_interface/qi_common/vpr_qi_external_api_interface.cpp, Line: 5961
Internal Error
Stack Trace:
   0x48ff70: VPR_QI_FACADE::unload + 0x110 (fitter_vpr20kmain)
    0xd1c57: BSYN_LABMGR_INTERFACE::operator= + 0xc9e77 (fitter_vpr20kmain)
   0x416e7d: BSYN_LABMGR_INTERFACE::operator= + 0x40f09d (fitter_vpr20kmain)
   0x6479d4: VPR_QI_FACADE::apl_incr_place_and_cluster + 0x1b7384 (fitter_vpr20kmain)
   0x2faabc: BSYN_LABMGR_INTERFACE::operator= + 0x2f2cdc (fitter_vpr20kmain)
   0x2f8aae: BSYN_LABMGR_INTERFACE::operator= + 0x2f0cce (fitter_vpr20kmain)
     0xb43e: BSYN_LABMGR_INTERFACE::operator= + 0x365e (fitter_vpr20kmain)
     0xa961: BSYN_LABMGR_INTERFACE::operator= + 0x2b81 (fitter_vpr20kmain)
    0x2696f: BSYN_LABMGR_INTERFACE::operator= + 0x1eb8f (fitter_vpr20kmain)
    0x5d2ee: BSYN_LABMGR_INTERFACE::operator= + 0x5550e (fitter_vpr20kmain)
    0x5c82c: BSYN_LABMGR_INTERFACE::operator= + 0x54a4c (fitter_vpr20kmain)
   0x229e88: BSYN_LABMGR_INTERFACE::operator= + 0x2220a8 (fitter_vpr20kmain)
   0x22934b: BSYN_LABMGR_INTERFACE::operator= + 0x22156b (fitter_vpr20kmain)
   0x48f96c: VPR_QI_FACADE::vpr_qi_main + 0x3c (fitter_vpr20kmain)
    0x35740: fitapi_run_vpr + 0x70 (fitter_fitapi)
    0x1bc7f: fsv_execute + 0x338f (fitter_fsv)
    0x1b6dd: fsv_execute + 0x2ded (fitter_fsv)
    0x1ab12: fsv_execute + 0x2222 (fitter_fsv)
    0x18912: fsv_execute + 0x22 (fitter_fsv)
     0xe142: fmain_start + 0x8e2 (FITTER_FMAIN)
    0x14410: TclInvokeStringCommand + 0xf0 (tcl86)
    0x161e2: TclNRRunCallbacks + 0x62 (tcl86)
    0x17a65: TclEvalEx + 0xa65 (tcl86)
    0xa6f8b: Tcl_FSEvalFileEx + 0x22b (tcl86)
    0xa5646: Tcl_EvalFile + 0x36 (tcl86)
    0x13962: qexe_evaluate_tcl_command + 0x582 (comp_qexe)
    0x12adc: qexe_apply_ini_vars + 0x29ec (comp_qexe)
    0x17c05: qexe_run_tcl_option + 0x575 (comp_qexe)
    0x34b13: qcu_run_tcl_option + 0xb63 (comp_qcu)
    0x1755a: qexe_process_cmdline_arguments + 0x246a (comp_qexe)
    0x18381: qexe_standard_main + 0xc1 (comp_qexe)
     0xcad8: msg_initialize_out_of_memory_handler + 0x378 (CCL_MSG)
     0xe20c: msg_set_stack_size + 0x7c (CCL_MSG)
     0x5aa0: mem_gen_get_project_output_directory + 0x64 (ccl_mem)
     0xc721: msg_exe_main + 0xa1 (CCL_MSG)
    0x159ec: BaseThreadInitThunk + 0xc (kernel32)
    0x2c540: RtlUserThreadStart + 0x20 (ntdll)
End-trace
Executable: quartus_fit
Comment:
None
System Information
Platform: windows64
OS name: Windows 7
OS version: 6.1
Quartus II Information
Address bits: 64
Version: 14.1.0
Build: 186
Edition: Web Edition

Does any of this mean anything to you?

See attached for the signaltap settings

The few times i did get it to compile, I would enter A or B or C on putty. I would imagine im supposed to see 65,66,67 on the uart_rx line?

So if this is correct, then the correct data gets to the board from putty...take a look at the signal tap captures

You suggest sending hello world out from nios. Can you help me set up the signal tap correctly so that i dont get this error? Any suggestions?

Also, would i just look at uart_tx and try to decode hello world from that?

So if all this is correct, then it seems like it might be the software layer? again, this sorta code worked ok for jtag_uart. usb_uart cant be that much different

thanks Dave!

--- Quote Start ---

Does any of this mean anything to you?

--- Quote End ---

Nope. If I get errors with Quartus I generally delete all the generated files and re-run a Tcl script to build the design again from scratch.

--- Quote Start ---

See attached for the signaltap settings

--- Quote End ---

The attachments are resampled too small. I'm not sure if they are what you uploaded, or whether the web interface resampled them. Try to upload a zip with the images, rather than as .jpg.

Although, I should not need to look at the images - you should.

What are you looking for? You need to check the baud rate! For example, if I look on an ASCII chart for the hex value 0x55 I see that it is a capital U. If I hit capital U, and then look at SignalTap II, I can measure the bit period in units of the SignalTap II clock, and from that I can confirm the baud.

That is what you need to do.

--- Quote Start ---

again, this sorta code worked ok for jtag_uart. usb_uart cant be that much different

--- Quote End ---

The two interfaces are nothing alike. The fact that it has UART in the name jtag_uart is completely bogus. Its not an asynchronous UART, its a synchronous JTAG interface that implements a fake UART by polling at a regular basis.

Cheers,

Dave

Hey Dave

Yes, you confirmed what i thought i should be looking for... A = d65, B= d66. So because my signal tap was working, i didnt want to recompile and rish that error. So, i went ahead and recompiled and triggered on TX and saw the usb rate from nios was different that what putty was kicking out. I tried adjusting the baud rate in the device manager/properties, but that does not change the bit rate on the signal tap. So, i started adjusting the rate on putty to match the trace on the signal tap. And at 24000 baud, things started working. So you were right.. its baud rate.

So ive got to figure out why it works at 24000 when

1)why the driver settings have no effect on the rate

2)the qsys parameters on the usb uart are at 9600

3)nothing i see anywhere mentions 24000...

i think there are baud rate multipliers somewhere that i might have to set.

any ideas on where to look would be great

again, thank you for bearing with me on this. i am just a little pilot fish

thanks for your help!

--- Quote Start ---

i went ahead and recompiled and triggered on TX and saw the usb rate from nios was different that what putty was kicking out. I tried adjusting the baud rate in the device manager/properties, but that does not change the bit rate on the signal tap. So, i started adjusting the rate on putty to match the trace on the signal tap. And at 24000 baud, things started working. So you were right.. its baud rate.

--- Quote End ---

Ok, good, that is progress :)

--- Quote Start ---

1)why the driver settings have no effect on the rate

--- Quote End ---

The Windows driver for the FTDI USB-to-UART pin *will* have an effect. You will only be able to see that effect if you type a character into Putty and observe the transmit pin from the FTDI device, which is connected to the RX on your FPGA UART, so you have to trigger SignalTap II off that signal.

--- Quote Start ---

2)the qsys parameters on the usb uart are at 9600

--- Quote End ---

Its quite possible that this only works correctly if you have the Qsys clk frequency set correctly. The default is 50MHz, so if you are actually connecting the Qsys clk input to a different frequency, then your Qsys clock frequency setting is wrong. If the Qsys UART _hw.tcl script uses that clock frequency to calculate divider settings, then they will be wrong.

--- Quote Start ---

i think there are baud rate multipliers somewhere that i might have to set.

any ideas on where to look would be great

--- Quote End ---

The NIOS II software API for the UART should have functions for you to access. You really need to read the user manual for the Qsys UART component.

Cheers,

Dave

Hi Dave

Yes, i triggered on the RX pin and typed in putty and got what i wanted. and had nios printf ABC and saw that show up in putty. so it works. im just not sure about why it works at 24000...

The clock rate for my system is 50MHz.

I read that UART core manual and see that the divisor can be read at UARTBaseAddr + 4...

heres my uart settings as described in system.h

# define ALT_MODULE_CLASS_uart_0 altera_avalon_uart

# define UART_0_BASE 0x20020800

# define UART_0_BAUD 9600

# define UART_0_DATA_BITS 8

# define UART_0_FIXED_BAUD 0

# define UART_0_FREQ 50000000

# define UART_0_IRQ 2

# define UART_0_IRQ_INTERRUPT_CONTROLLER_ID 0

# define UART_0_NAME "/dev/uart_0"

# define UART_0_PARITY 'N'

# define UART_0_SIM_CHAR_STREAM ""

# define UART_0_SIM_TRUE_BAUD 0

# define UART_0_SPAN 32

# define UART_0_STOP_BITS 1

# define UART_0_SYNC_REG_DEPTH 2

# define UART_0_TYPE "altera_avalon_uart"

# define UART_0_USE_CTS_RTS 0

# define UART_0_USE_EOP_REGISTER 0

So if i read the uart divisor reg in system console, i get

master_read_memory $master 0x20020800 10

0x41 0x00 0x00 0x00 0x43 0x00 0x00 0x00 0x60 0x00

x43 is my divisor??

If thats the case, then applying the equations in the uart core handbook:

baudrate = clkfrq/(divisor + 1)

and

divisor =int (clk_freq/baudrate +.5)

my baudrate should be 50e6/(d67+1) = 735Kbaud???

or calculating the theoretical divisor... 50e6/24000 +.5 = d2084 = x824

So something is not correct or my understanding is wrong

Im going to try regenerating everything from scratch to see if that makes any difference

Any thoughts?

thanks

So i quickly tried

alt_u16 divisorSetting = IORD_ALTERA_AVALON_UART_DIVISOR(UART_0_BASE);

and that spit out 5208 so doing that math, my baud rate would be 9600

I do have the "change the baudrate via SW" button checked, but it used to be disabled in a previous build. ill redo everything and see if things dont jive then

But assuming that IORD_ALTERA_AVALON_UART_DIVISOR(UART_0_BASE) yields a correct divisor (i do have qsys calling for 9600), then the ftdi is modifying the qsys rate and kicking something else out.

im going to look at ftdi config...

--- Quote Start ---

So i quickly tried

alt_u16 divisorSetting = IORD_ALTERA_AVALON_UART_DIVISOR(UART_0_BASE);

and that spit out 5208 so doing that math, my baud rate would be 9600

--- Quote End ---

You have not clearly stated (to me) your "real" problem. You've got two possibilities;

1. The Qsys UART baud rate is wrong.

Diagnostic: probe the Qsys UART transmit signal using SignalTap II and calculate the actual baud rate. Is is correct?

2. The FTDI USB-to-UART is wrong.

Diagnostic: probe the Qsys UART receive signal using SignalTap II and calculate the actual baud rate. Is is correct?

Its highly unlikely that the FTDI transmit signal (Qsys UART receive signal) is wrong if you have configured the baud rate in Putty correctly, but you should confirm that. For example, perhaps you assumed your board has a 50MHz clock, when in fact it has a different frequency. If your SignalTap II instance is using the same clock, then the captured trace timing will appear incorrect.

Cheers,

Dave