Hello,

I am trying to run a project created for SHARC processor. I have a C function that is called
from an assembly routine. When I run the project the emulator stops at the first line of the C
function and outputs this funny message:

"target halted due to software breakpoint but no breakpoint found at address..."

I know that the problem is related to interrupts. When I click on F11 (step into) the control
enters an interrupt service routine. But whenever I try F5 (run) it halts immediately at the
first line of the C function again and outputs the same message above. It just can't run
continuosly.
There is no problem when assembly routines are interrupted, it just happens with this C code. 

Anyone had a similar problem?

cheers,
Ivan   

------------------------------------

On Thu, 17 Jul 2008 i...@hotmail.com wrote:

> Hello,
>
> I am trying to run a project created for SHARC processor. I have a C
>function that is called from an assembly routine. When I run the project
>the emulator stops at the first line of the C function and outputs this
>funny message:
>
> "target halted due to software breakpoint but no breakpoint found at
address..."
>
 > I know that the problem is related to interrupts. When I click on F11
>(step into) the control enters an interrupt service routine. But whenever
>I try F5 (run) it halts immediately at the first line of the C function
>again and outputs the same message above. It just can't run continuosly.
> There is no problem when assembly routines are interrupted, it just
>happens with this C code.
>
> Anyone had a similar problem?

Not the same problem, but I can understand where it might come from.  If a
bit set irptl instruction is the first instruction it will cause a
software interrupt.  Since that is used by the debugger to mark break
points, but no breakpoints are actually set, the debugger gets confused.

In assembler, you probably have an RTI for software interrupts, so you
don't notice anything.  If you put in a here: jump here for the software
irq routine, it will halt the processor and you will notice nothing is
working.

So the real problem is why is the compiler putting in a set bit irptl
instruction in your C routine?  Maybe you have some flag that needs to be
changed in the compiler?

Patience, persistence, truth,
Dr. mike
------------------------------------

Hi,
  I am not sure if your hardware board has  Watch Dog Timer (WDT),  
that generates a reset interrupt after a predefine period. I used to  
face a similar problem while working in emulator mode. Due to the  
reset by the WDT, the control used to get transfered to the interrupt  
reset vector, and the program could never enter the main operation.
  During the run-time initialization you can disable interrupt (IRPLT  
and IMASK register) and once the initialization is complete you can  
enable interrupt if you are using them.
   Also, if any external periodic interrupt is connected to the  
hardware, that may cause it to go the ISR.

Santanu

Quoting Mike Rosing <e...@eskimo.com>:

> On Thu, 17 Jul 2008 i...@hotmail.com wrote:
>
>> Hello,
>>
>> I am trying to run a project created for SHARC processor. I have a C
>> function that is called from an assembly routine. When I run the project
>> the emulator stops at the first line of the C function and outputs this
>> funny message:
>>
>> "target halted due to software breakpoint but no breakpoint found   
>> at address..."
>>
>  > I know that the problem is related to interrupts. When I click on F11
>> (step into) the control enters an interrupt service routine. But whenever
>> I try F5 (run) it halts immediately at the first line of the C function
>> again and outputs the same message above. It just can't run continuosly.
>> There is no problem when assembly routines are interrupted, it just
>> happens with this C code.
>>
>> Anyone had a similar problem?
>
> Not the same problem, but I can understand where it might come from.  If a
> bit set irptl instruction is the first instruction it will cause a
> software interrupt.  Since that is used by the debugger to mark break
> points, but no breakpoints are actually set, the debugger gets confused.
>
> In assembler, you probably have an RTI for software interrupts, so you
> don't notice anything.  If you put in a here: jump here for the software
> irq routine, it will halt the processor and you will notice nothing is
> working.
>
> So the real problem is why is the compiler putting in a set bit irptl
> instruction in your C routine?  Maybe you have some flag that needs to be
> changed in the compiler?
>
> Patience, persistence, truth,
> Dr. mike

------------------------------------

Thank you Mike and Santanu for your suggestions. The original problem dissappeared when I
reset Visual DSP. (It's sad that reset is such a powerful tool in software engineering!) But
then the emulator decided to halt again at the very last line of the same function for no good
reason. That also dissapeared and the program is now running OK but I don't know for how long.

Anyway, when C code is called from assembly routines some really weird things happen. The C
functions that I am calling are not consistent at all. Sometimes they work sometimes they don't
and I am still wrestling with that problem. It's probably something to do with C/C++
environment initialization that I discussed in an earlier post. Analog Devices documentation,
which is otherwise good, does not treat this topic well.

Cheers,
Ivan  

Hello,
>
>I am trying to run a project created for SHARC processor. I have a C function that is
called from an assembly routine. When I run the project the emulator stops at the first line of
the C function and outputs this funny message:
>
>"target halted due to software breakpoint but no breakpoint found at address..."
>
>I know that the problem is related to interrupts. When I click on F11 (step into) the
control enters an interrupt service routine. But whenever I try F5 (run) it halts immediately
at the first line of the C function again and outputs the same message above. It just can't run
continuosly.
>There is no problem when assembly routines are interrupted, it just happens with this C
code. 
>
>Anyone had a similar problem?
>
>cheers,
>Ivan   
>
>------------------------------------

------------------------------------

Quoting i...@hotmail.com:

> Thank you Mike and Santanu for your suggestions. The original   
> problem dissappeared when I reset Visual DSP. (It's sad that reset   
> is such a powerful tool in software engineering!) But then the   
> emulator decided to halt again at the very last line of the same   
> function for no good reason. That also dissapeared and the program   
> is now running OK but I don't know for how long.
>
> Anyway, when C code is called from assembly routines some really   
> weird things happen. The C functions that I am calling are not   
> consistent at all. Sometimes they work sometimes they don't and I am  
>  still wrestling with that problem.

   Did you properly use the compiler and scratch pad registers? You  
have to push them to stack before being used and pop them berofe  
returning. Only scratch pad registers (R4, R12) can be used. Also the  
L registerd need to be initialized to zero before returning from the  
asm function. I also faced couple of similar problems in using the c  
and assembly interface functions.

It's probably something to do
> with C/C++ environment initialization that I discussed in an earlier  
>  post. Analog Devices documentation, which is otherwise good, does   
> not treat this topic well.
>
> Cheers,
> Ivan
>
> Hello,
>>
>> I am trying to run a project created for SHARC processor. I have a   
>> C function that is called from an assembly routine. When I run the   
>> project the emulator stops at the first line of the C function and   
>> outputs this funny message:
>>
>> "target halted due to software breakpoint but no breakpoint found   
>> at address..."
>>
>> I know that the problem is related to interrupts. When I click on   
>> F11 (step into) the control enters an interrupt service routine.   
>> But whenever I try F5 (run) it halts immediately at the first line   
>> of the C function again and outputs the same message above. It just  
>>  can't run continuosly.
>> There is no problem when assembly routines are interrupted, it just  
>>  happens with this C code.
>>
>> Anyone had a similar problem?
>>
>> cheers,
>> Ivan
>>
>> ------------------------------------
>>
>
------------------------------------