|
I'm back to V3.5 for the moment and have a question.. Even though I've built in debug mode there are many places where I can't set a breakpoint as I get the following warning : Warning: Address 0x000210ef contains a restricted breakpoint instruction. A breakpoint at this location may not operate as expected. Some places in the same source breakpoints don't generate the warning and some don't. Why is this? I thought in Debug mode I should be able to place a breakpoint just about anywhere. Steve Holle Link Communications, Inc. 1035 Cerise Rd. Billings, MT 59101 |
|
|
VDSP++ V3.5
Started by ●February 22, 2005
Reply by ●February 22, 20052005-02-22
|
On Tue, 22 Feb 2005, Steve Holle wrote: > > I'm back to V3.5 for the moment and have a question.. > > Even though I've built in debug mode there are many places where I can't > set a breakpoint as I get the following warning : > Warning: Address 0x000210ef contains a restricted breakpoint > instruction. > A breakpoint at this location may not operate as expected. > Some places in the same source breakpoints don't generate the warning and > some don't. Why is this? I thought in Debug mode I should be able to > place a breakpoint just about anywhere. Just a guess, but it may be a hardware rather than software break, or it may be trying to set a memory access break rather than an instruction execution break. If it thinks it is rom space then it knows it can't set a software break. You should be able to set 3 hardware breaks without a problem, so it may also be you have 4 or 5 breaks set, and it isn't setting any software breaks so that's another reason it's giving a warning. Don't know for sure, could be a bit got flipped someplace that wasn't supposed to be as well. Patience, persistence, truth, Dr. mike |
Reply by ●February 22, 20052005-02-22
|
Hi Steve, Maybe I'm wrong, if so please somebody correct me. As far as I recall that for most of the ADSP processors (I bet you are working on SHARC, and in that case this applies), the restrictions are in instructions like jumps or the final instruction of a loop. Not simply due to being off debug mode. JaaC --- Steve Holle <> wrote: > > I'm back to V3.5 for the moment and have a > question.. > > Even though I've built in debug mode there are many > places where I can't > set a breakpoint as I get the following warning : > Warning: Address 0x000210ef contains a > restricted breakpoint > instruction. > A breakpoint at this location may not > operate as expected. > Some places in the same source breakpoints don't > generate the warning and > some don't. Why is this? I thought in Debug mode I > should be able to > place a breakpoint just about anywhere. > > Steve Holle > Link Communications, Inc. > 1035 Cerise Rd. > Billings, MT 59101 > ===== Jaime Andr Aranguren Cardona __________________________________________________ |
Reply by ●February 23, 20052005-02-23
|
Hi all, I'm developing ADSP-2183 based board. I am using flash memory for booting of the processor by BDMA. i am writing my code in flash by external processor board, and reading from that board, i am getting same data whatever i'm writing, but when i am reading that location with the help of emulator (writing a code for BDMA transfer from 0x0 location of the flash to the DM of processor and reading that location) on the PC i am getting different data. initial data is same (some 0x34 bytes) but then different data. everytime i'm reading through processor i'm getting same data. even booting through that flash also dosn't give required function. Thanks in advance Amit |
Reply by ●February 23, 20052005-02-23
|
Am Dienstag, 22. Februar 2005 22:52 schrieben Sie: > I'm back to V3.5 for the moment and have a question.. > > Even though I've built in debug mode there are many places where I can't > set a breakpoint as I get the following warning : > Warning: Address 0x000210ef contains a restricted breakpoint > instruction. > A breakpoint at this location may not operate as expected. > Some places in the same source breakpoints don't generate the warning and > some don't. Why is this? I thought in Debug mode I should be able to > place a breakpoint just about anywhere. Hi Steve, I've seen such warnings often (on Sharc). Somtimes, it's (as described in another post) because you placed the breakpoint around a jump/call or (db) statement, where the prefetch/caching mechanism of the processor might hide the breakpoint such that it would fail during execution. This might happen, if you set the breakpoint in the disassembly window. The solution would be to move the breakpoint to a correct position (maybe you need an additional nop; or _nop() in your code) Sometimes, it's a residual breakpoint which had been set earlier, but then some code reorganisation after a new compile/link/load changed something. I'd expect that the IDDE would cope with this correctly, but in some situations I found that warnings like yours could result. It may look like a correctly placed breakpoint. If you switch to mixed mode, you might see, that the breakpoint is not on the first statement of this code line anymore. Solution here: remove breakpoint and set it to the correct line again. If this doesn't help, proceed as below. There's another situation where an old breakpoint raises a warning like yours, or in some other situations I found that it doesn't raise a warning, but the code execution just stops on a breakpoint which is invisible/not existent. I found that you can overcome the troublesome situation by pressing the "Remove all breakpoints" button, and the reinstalling the breakpoints. I didn't find another solution. This may not be sufficient to explain all the strange behaviour, and in fact, I don't have explanations. However, as a pragmatic approach, it helped me most of the time, and I hope, that you'll benefit of my experiences, too. Good luck. Bernhard > > Steve Holle > Link Communications, Inc. > 1035 Cerise Rd. > Billings, MT 59101 |
Reply by ●February 23, 20052005-02-23
|
Maybe a simple solution: Even in debug mode, you could have turned on optimisations... Friedrich > -----Original Message----- > From: Steve Holle [mailto:] > Sent: Tuesday, February 22, 2005 10:53 PM > To: > Subject: [adsp] VDSP++ V3.5 > > I'm back to V3.5 for the moment and have a question.. > > Even though I've built in debug mode there are many places > where I can't > set a breakpoint as I get the following warning : > Warning: Address 0x000210ef contains a restricted breakpoint > instruction. > A breakpoint at this location may not operate as > expected. Some places in the same source breakpoints don't > generate the warning and > some don't. Why is this? I thought in Debug mode I should > be able to > place a breakpoint just about anywhere. > > Steve Holle > Link Communications, Inc. > 1035 Cerise Rd. > Billings, MT 59101 > > |
Reply by ●February 23, 20052005-02-23
|
Hi Jaime and Steve, Jaime is correct about restrictions with breakpoints being applied to delayed instructions or indeed the delayed slots following the instructions . If you are receiving these warnings on instructions where there is no delayed branch and the breakpoint is not in the two instruction lines following the delayed branch then I would try creating a new session. Just replace the existing session with one of the same name. It will ask you if you want to overwrite the session. I have found that this can sometimes resolve some issues if a session has saved any breakpoint info from a previous build of the project. Alternatively open the breakpoints window when the project is open and clear all the breakpoints from in there. Re-save your project then re-open it. This has the same effect. Regards Rich > Hi Steve, > >Maybe I'm wrong, if so please somebody correct me. > >As far as I recall that for most of the ADSP >processors (I bet you are working on SHARC, and in >that case this applies), the restrictions are in >instructions like jumps or the final instruction of a >loop. > >Not simply due to being off debug mode. > >JaaC > >--- Steve Holle <> wrote: > >> >> I'm back to V3.5 for the moment and have a >> question.. >> >> Even though I've built in debug mode there are many >> places where I can't >> set a breakpoint as I get the following warning : >> Warning: Address 0x000210ef contains a >> restricted breakpoint >> instruction. >> A breakpoint at this location may not >> operate as expected. >> Some places in the same source breakpoints don't >> generate the warning and >> some don't. Why is this? I thought in Debug mode I >> should be able to >> place a breakpoint just about anywhere. >> >> Steve Holle >> Link Communications, Inc. >> 1035 Cerise Rd. >> Billings, MT 59101 >> > >===== > >Jaime Andr Aranguren Cardona > > >__________________________________________________ > > > |
Reply by ●February 23, 20052005-02-23
|
On Tue, 22 Feb 2005, Jain Amit wrote: > I'm developing ADSP-2183 based board. I am using flash > memory for booting of the processor by BDMA. i am > writing my code in flash by external processor board, > and reading from that board, i am getting same data > whatever i'm writing, but when i am reading that > location with the help of emulator (writing a code for > BDMA transfer from 0x0 location of the flash to the DM > of processor and reading that location) on the PC i am > getting different data. initial data is same (some > 0x34 bytes) but then different data. everytime i'm > reading through processor i'm getting same data. even > booting through that flash also dosn't give required > function. > Thanks in advance By different, do you mean the bits are messed up, or do you mean it's the same data in the wrong order? I've had lots of problems getting flash rom to boot because I had all the bytes in the wrong place! If the bits are messed up, then you just need to check the hardware lines between the flash and the processor. If the order is messed up, you need to mess 'em up in the proper order before burning the flash. Should be an easy fix either way :-) Good luck! Patience, persistence, truth, Dr. mike |
Reply by ●February 23, 20052005-02-23
|
This problem is most troubling in switch/case statements where, it seems, I
can hardly find a line that allows a valid set point. At 11:50 PM 2/22/2005, Bernhard Holzmayer wrote: >Am Dienstag, 22. Februar 2005 22:52 schrieben Sie: > > I'm back to V3.5 for the moment and have a question.. > > > > Even though I've built in debug mode there are many places where I can't > > set a breakpoint as I get the following warning : > > Warning: Address 0x000210ef contains a restricted breakpoint > > instruction. > > A breakpoint at this location may not operate as expected. > > Some places in the same source breakpoints don't generate the warning and > > some don't. Why is this? I thought in Debug mode I should be able to > > place a breakpoint just about anywhere. > >Hi Steve, > >I've seen such warnings often (on Sharc). >Somtimes, it's (as described in another post) because you placed the >breakpoint around a jump/call or (db) statement, where the prefetch/caching >mechanism of the processor might hide the breakpoint such that it would fail >during execution. This might happen, if you set the breakpoint in the >disassembly window. The solution would be to move the breakpoint to a correct >position (maybe you need an additional nop; or _nop() in your code) > >Sometimes, it's a residual breakpoint which had been set earlier, but then >some code reorganisation after a new compile/link/load changed something. I'd >expect that the IDDE would cope with this correctly, but in some situations I >found that warnings like yours could result. It may look like a correctly >placed breakpoint. If you switch to mixed mode, you might see, that the >breakpoint is not on the first statement of this code line anymore. >Solution here: remove breakpoint and set it to the correct line again. >If this doesn't help, proceed as below. > >There's another situation where an old breakpoint raises a warning like yours, >or in some other situations I found that it doesn't raise a warning, but the >code execution just stops on a breakpoint which is invisible/not existent. >I found that you can overcome the troublesome situation by pressing the >"Remove all breakpoints" button, and the reinstalling the breakpoints. I >didn't find another solution. > >This may not be sufficient to explain all the strange behaviour, and in fact, >I don't have explanations. However, as a pragmatic approach, it helped me >most of the time, and I hope, that you'll benefit of my experiences, too. > >Good luck. >Bernhard > > > > > Steve Holle > > Link Communications, Inc. > > 1035 Cerise Rd. > > Billings, MT 59101 > > > > Steve Holle Link Communications, Inc. 1035 Cerise Rd. Billings, MT 59101 |
Reply by ●February 23, 20052005-02-23
|
Good question. I checked and optimization is off. At 01:18 AM 2/23/2005, Burgwedel Friedrich wrote: >Maybe a simple solution: Even in debug mode, you could have turned on >optimisations... > >Friedrich > > > -----Original Message----- > > From: Steve Holle [mailto:] > > Sent: Tuesday, February 22, 2005 10:53 PM > > To: > > Subject: [adsp] VDSP++ V3.5 > > > > > > > > I'm back to V3.5 for the moment and have a question.. > > > > Even though I've built in debug mode there are many places > > where I can't > > set a breakpoint as I get the following warning : > > Warning: Address 0x000210ef contains a restricted breakpoint > > instruction. > > A breakpoint at this location may not operate as > > expected. Some places in the same source breakpoints don't > > generate the warning and > > some don't. Why is this? I thought in Debug mode I should > > be able to > > place a breakpoint just about anywhere. > > > > Steve Holle > > Link Communications, Inc. > > 1035 Cerise Rd. > > Billings, MT 59101 > > > > > > > > > > > > > > > > > > > > > > > > > > Steve Holle Link Communications, Inc. 1035 Cerise Rd. Billings, MT 59101 |
