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
microblaze firmware + UART handshaking blues
Started by ●February 10, 2008
Reply by ●February 10, 20082008-02-10
On Feb 10, 5:20 pm, chrisde...@gmail.com wrote:> 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! > ChrisWell 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 by ●February 11, 20082008-02-11
GMM50 wrote:> On Feb 10, 5:20 pm, chrisde...@gmail.com wrote: >> 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 > > 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. >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.> 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 by ●February 11, 20082008-02-11
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:> On Feb 10, 5:20 pm, chrisde...@gmail.com wrote: > > 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 > > 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 by ●February 11, 20082008-02-11
On Feb 11, 8:55 am, chrisde...@gmail.com wrote:> 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: > > On Feb 10, 5:20 pm, chrisde...@gmail.com wrote: > > > 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 > > > 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. > > > georgeI 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 by ●February 12, 20082008-02-12
On Feb 11, 10:55 am, chrisde...@gmail.com wrote: <snip> 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. <snip> 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 by ●February 12, 20082008-02-12
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 On Feb 12, 11:47=A0pm, Dave Pollum <vze24...@verizon.net> wrote:> On Feb 11, 10:55 am, chrisde...@gmail.com wrote: > <snip> > 1) rts on PC side will drive FPGA cts pin. If rts on PC side =3D 1, then > transmission =A0from 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 =3D 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. > <snip> > > to paraphrase: > #1: RTS(PC) =A0 -> CTS(FPGA) =A01 =3D FPGA transmits to PC > #2: RTS(FPGA) -> CTS(PC) =A0 =A01 =3D PC _does not_ transmit to FPGA > > Is this really what happens, or did you mistype? > -Dave Pollum
Reply by ●February 13, 20082008-02-13
On Feb 12, 5:33 pm, chrisde...@gmail.com wrote:> Hi Dave, > > my mistake. Here is what i intended it to be. > > to paraphrase: > #1: RTS(PC) -> CTS(FPGA) 0 = PC has no data to send to FPGA. If PC > sends data without asserting its RTS, > UART will not shift > in the inputs. > 1= 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 = 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 = 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 > > On Feb 12, 11:47 pm, Dave Pollum <vze24...@verizon.net> wrote: > > > On Feb 11, 10:55 am, chrisde...@gmail.com wrote: > > <snip> > > 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. > > <snip> > > > 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 PollumHi All: This may indeed be a problem but how does debug make it all work. george
Reply by ●February 13, 20082008-02-13
GMM50 wrote:> Hi All: > > This may indeed be a problem but how does debug make it all work. > > georgeIn 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 by ●February 13, 20082008-02-13
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 On Feb 14, 5:58=A0am, Alex Freed <al...@mirrow.com> wrote:> GMM50 wrote: > > Hi All: > > > This may indeed be a problem but how does debug make it all work. > > > george > > 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.