Re: Debugging NIOS code in hardware while TIMER is running.

Altera_Forum · ‎12-19-2012

Hi,

Im running my NIOS code i hardware and want to step through the code from a certain breakpoint but its not possible.

I guess that my problem is that the timer is running.

main(){
   ..
   ...
   .
   timer_init();   //10ms
   while(1){
      .
      ...
      funcX();        
      ...
   }
}
funcX(){
   ...
   ....
   break!!!
   ...
   ...
   ...
   ..
}

Is it possible to debug a function while a timer is running?

Altera_Forum · ‎12-19-2012

Welcome to the world of device driver debugging.

Basically the world doesn't stop to let you breakpoint/single step code.

General techniques:

1) printf - but that is often too slow and you generate too much data for any uart.

2) Allocate a trace array and write info to it. If you make each entry 16 bytes it will hexdump nicely, write a value that happens to be a 4 character string to the first entry to make them easier to identify.

3) Use a hardware monitor to trace all the bus cycles. You can use signaltap for this, but finding the correct nodes is 'interesting'. We monitored the accesses to the (tightly coupled) m9K memory blocks. I don't know if you can tap the address/data interface to the instruction and data caches.

Altera_Forum · ‎12-19-2012

Thanks for clarify limitations in debugging while timer running.

I had hoped that it was not necessary to add trace signals see the flow with signaltap.

Lucky for me that the code is executed from external SRAM so it's easy to find data/addr pins.

Altera_Forum · ‎12-19-2012

You'll only see cache reads and writes - they won't be over-informative.

Altera_Forum · ‎12-19-2012

Hmm... OK also if im using a NIOS II/e cpu?

Altera_Forum · ‎12-19-2012

--- Quote Start ---

Hi,

Im running my NIOS code i hardware and want to step through the code from a certain breakpoint but its not possible.

--- Quote End ---

What exactly your problem is?

In general you should be able to step through you code unless you hit one of these conditions:

- code strongly dependent on varying external signals or on a timer; however in this case you should be able to step through the code, although the flow may be somewhat different from 'run' mode, because some variables are changing not the way they are supposed to.

- an interrupt is continuously triggered by the timer or any other external signal and this would always take you to the isr whenever you hit a breakpoint and try to step into the code

- watchdog circuitry enabled; this won't allow you to stop execution.