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

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

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

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

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.
>
> > george

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

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

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

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 Pollum

Hi All:

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

george

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.

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.