1. Home
  2. Embedded Programming
  3. microblaze firmware + UART handshaking blues

microblaze firmware + UART handshaking blues

Hi, I am currently working on a microblaze v6.00 core on FPGA and am developing an algorithm. This is what I am doing

1) matlab on PC sends data to microblaze (FPGA) via UART. RS232 hardware handshaking is deployed here. 2) the algorithm runs on microblaze to process the input data 3) microblaze sends the data back to matlab on PC.

the setup I am working on works perfectly on a previous FPGA board. I have just migrated the setup to another FPGA board for FPGA resource expansion reasons. However, microblaze no longer sends the data back to PC. Here are some other details

1) I have ensured that the board is able to send data back and forth from PC to microblaze via UART in both directions in matlab. thus code like this works: int main() { get_params(); //get data from UART using blocking statements return_result(); //return results back to PC via UART. }

2) the C code which doesnt work however looks like this in normal operation unless I am in debug mode. :(

int main(){ get_params(); //get data from UART using blocking statements start_algo(); //to start algo return_result(); //return results back to PC via UART. }

void start_algo(){ // I inserted a breakpoint around here. ...the rest of the algo.... }

when I use a debugger to debug, by inserting a breakpoint somewhere up in the start_algo() function. Whenever I do that, the return_result() function works just fine and returns the expected data correctly.

However, normal operation (without use of a debugger) just fails to work. I have been working on this for quite a while and am clueless how else further to debug.

any suggestions would really help.

thanks in advance! Chris

Reply to
chrisdekoh
Loading thread data ...

Well I would first look at compiler optimizations. Some time debug operation has NO optimizations while 'release' has some. Look at the code produces with and with out. If it's not IDENTICAL then that a good place to look.

Then break points might give hardware a chance to ketch up. Try debug with no breakpoints. That should also yield clues.

Switch to Altera and NIOS. (Just kiddine).

keep us posted.

george

Reply to
GMM50

Code that works when optimisations are turned off, and that fails when optimisations are turned on, is incorrect code - look for things like missing "volatile" declarations.

That said, playing with the optimisation settings might give you a clue as to what is going wrong.

Reply to
David Brown

Hi, disabling optimisations still do not work. the hardware peripherals attached to microblaze is only

1) UART 2) a simple timer

so the issue does not seem to be about optimisations. Also realised that, it only works in debug mode with the breakpoint set just before the algorithm commences. If the breakpoint is set in the middle of the function start_algo(), the same thing happens; no data is sent back to UART.

Can it be an issue of hardware catching up? the UART data is read via blocking statements!!

In any case, the UART is the free opb_uartlite provided by xilinx, which i hacked to allow hardware handshaking. I did this, so that I could use the default drivers for opb_uartlite with the same UART with additional functionality of hardware handshaking. No further register manipulation in software is necessary in this case to do hardware handshaking like for the case of the UART16550. This is what I did to enable hardware handshaking without any additional software needed.

1) rts on PC side will drive FPGA cts pin. If rts on PC side = 1, then transmission from FPGA to PC will be possible. otherwise, the FPGA cannot transmit anything back to PC. 2) cts on PC side is driven by FPGA rts pin. FPGA rts pin = 1 once the receiver buffer in UART peripheral attached to microblaze is full. this will disable PC from sending any more data to microblaze on the FPGA.

this method of UART handshaking seems to be working all this while on the previous FPGA board with PC. I have also tested and ensured that it works fine with this current board and PC (using both telnet and simple matlab routines, as described in my original post).

Any other ideas? Something that i might have failed overlooked? thank you all in advance.

Chris

GMM50 wrote:

Reply to
chrisdekoh

I would try to slow the UART down and run with out interrupts and with out handshaking. There's not much else to get in the way. You didn't mention a timer interrupt. If there are any other interrupts enabled I would try to run without them. The thought is debug is protecting you n some way from something missing in an interrupt routine.

keep us posted george

Reply to
GMM50
1) rts on PC side will drive FPGA cts pin. If rts on PC side = 1, then transmission from FPGA to PC will be possible. otherwise, the FPGA cannot transmit anything back to PC. 2) cts on PC side is driven by FPGA rts pin. FPGA rts pin = 1 once the receiver buffer in UART peripheral attached to microblaze is full. this will disable PC from sending any more data to microblaze on the FPGA.

to paraphrase: #1: RTS(PC) -> CTS(FPGA) 1 = FPGA transmits to PC #2: RTS(FPGA) -> CTS(PC) 1 = PC _does not_ transmit to FPGA

Is this really what happens, or did you mistype?

-Dave Pollum

Reply to
Dave Pollum

Hi Dave,

my mistake. Here is what i intended it to be.

to paraphrase: #1: RTS(PC) -> CTS(FPGA) 0 =3D PC has no data to send to FPGA. If PC sends data without asserting its RTS, UART will not shift in the inputs. 1=3D PC should assert this if it has data to send. only then can FPGA can receive data from PC

#2: RTS(FPGA) -> CTS(PC) 0 =3D receive buffer on UART attached to microblaze is full. During this time, PC should no longer transmit to FPGA. once receive buffer has been cleared, FPGA will set the RTS line again. 1 =3D PC can transmit to FPGA as the UART receive buffer is not full.

did you spot any mistake? Is there a need for FPGA to use DSR?

Chris

Reply to
chrisdekoh

Hi All:

This may indeed be a problem but how does debug make it all work.

george

Reply to
GMM50

In my experience the most common scenario is a lack of "volatile" keyword. Debug version turns optimization off and release version optimizes a read of a hardware register out, 'cause it doesn't know it is hardware and nothing in the code changes it's value.

The second possibility is a race condition. Dubug version may execute more slowly.

-Alex.

Reply to
Alex Freed

Hi,

1) Does a microprocessor in debug mode run on a slower clock? I din know that 2) under what circumstances should what variables be volatile?

Chris

Reply to
chrisdekoh

Sometimes cpus will run slower when you are using a debugger (for example, the debugger might have tracing features that require the cpu's cache to be disabled, or it might "simplify" the processor in other ways). However, I think what Alex meant was that the debug compile flags will generate slower code than when you pick flags for more optimisation. When using debug flags, the compiler will try to keep the structure of your program intact (such as its loops and functions), to make it easier to follow with a debugger. When doing full optimisation, the compiler will do more inlining and loop unrolling if that makes the code smaller and/or faster.

A variable should be "volatile" to indicate that its value might be read or changed without the compiler knowing about it (including being accessed from another C function if the compiler does not know that it may also run at any time, such as an interrupt function or a separate thread).

mvh.,

David

Reply to
David Brown

DONT look for incorrect code !

write correct code .

It should have occurred to you the

s/w you bought could never create

good bug free code !

The authors had no intention to sell

you a better way to generate code !

There is only one way to write good

code , write it all , yourself .

You begin by sending serial ( rs232 or SPI)

strings to ARM , running them .

The ones that dont crash and light up the

red , green , and blue LEDs in the right

order are your "tutorial" .

Learn to create code that assembles

and stores short Forth primatives in a

dictionary , so you can use these primatives

to help you create higher level sequences

of code .

Chuck Moore did this in the 70's , in Tucson to put many programmers out of a job . He created Forth ( the simplist method to program).

You will save many months of "learning" curve by not reading thick s/w manuals , you can charcterize the ARM yourself , with Forth , in minutes , and save the results to the Forth dictionary , to aide others .

There is no future , for M$ , C , Linux , and the PC ...

why not study modern techniques and burn your s/w "Books" ?

All critical s/w is written NOT using C , and NOT using available assemblers Not using Linux , Not using Intel , AMD cpu's

........... More than 2.5 billion A.R.M cpu's on this earth , the Thumb-2 instruction set is used more than the 32 bit instructions cause its faster !

The ST electronics company makes ST-710-FZ2 ARM 7 , has 144 pins 6 mhz I/O , internal 65 K SRAM and huge flash . It will be configured with 32MB PSRAM . and a non-prop USB 480 mb/s serial port ( "Hi-Speed... Run Length Limited h/w).

PC is dead ,

ARM-BC ( business computer follows)

KC7CC

Reply to
werty

etc. etc.

Is it me??

Dave.

Reply to
Dave

Yes. You failed to PLONK werty.

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
            Try the download section.
Reply to
CBFalconer

No, it's him - like one of those Japanese soldiers holed up on an island, still waiting for orders long after the war was lost.

Mike

Reply to
MikeShepherd564

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.