• Locked Locked
  • Replies 5 replies
  • Subscribers 119 subscribers
  • Views 3487 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Using Watchpoints within ARM assembler code

aricker78 aricker78
Note: This was originally posted on 2nd October 2009 at http://forums.arm.com

Dear all!

We are working with an ARM926EJS core (netX500 from Hilscher). For a safety application, I need to guarantee, that only safety code (written according to special coding guidelines and 100% tested) can set special GPIOs.
To separate the "standard" GPIOs from the "safety" GPIOs, I cannot use the MMU, as the MMU tables can only be programmed in steps of 1kB.

Therefore, I got the idea to use the debug unit. When standard code is run, there would be a watchpoint which will react, if standard code wants to set safety GPIOs.

Is it possible to enable a watchpoint out of ARM assembler code (by programming CP14 in a special way)?

If yes: What happens, if the watchpoint is getting active? Would be nice, if I would get an data abort or something like this, but I think, the ARM processor will try to signalize something to the debugger (which would not be there in my case)...

It would be nice, if somebody of you could share some ideas or information about this with me!

Thanks in advance,
Andreas Rickert
Parents
  • Note: This was originally posted on 6th October 2009 at http://forums.arm.com

    Dear all,

    I think I was a little bit blended by my own "genious" idea...
    You are absolutely right. When the debugger stops, the write access was already done. Therefore, it would not be suitable...

    Marcus, you wrote:
    How about making GPIO only accessible from safety code?


    How would you do this? My only idea is to protect the whole area, where the GPIOs are located, by MMU. An access will generate a data abort and I can then decide, if the access is ok.
    But, I don't know in detail at the moment, what information the data abort gives me.
    I have the adress of the instruction, which caused it in R14.
    But then, I need to analyze this instruction in order to know, which register should be written to the adress.

    The problem with writing a separate API is, that the non-safe code is already there (CANOpen stack, operating system, ...). We are using the free FIQ interrupt to add our safety code in time-multiplex. Therefore, the CANOpen stack for example uses the API of the standard operating system... No way to add my own API with little effort...

    Any ideas?

    Kind regards and thanks in advance,
    Andreas
Reply
  • Note: This was originally posted on 6th October 2009 at http://forums.arm.com

    Dear all,

    I think I was a little bit blended by my own "genious" idea...
    You are absolutely right. When the debugger stops, the write access was already done. Therefore, it would not be suitable...

    Marcus, you wrote:
    How about making GPIO only accessible from safety code?


    How would you do this? My only idea is to protect the whole area, where the GPIOs are located, by MMU. An access will generate a data abort and I can then decide, if the access is ok.
    But, I don't know in detail at the moment, what information the data abort gives me.
    I have the adress of the instruction, which caused it in R14.
    But then, I need to analyze this instruction in order to know, which register should be written to the adress.

    The problem with writing a separate API is, that the non-safe code is already there (CANOpen stack, operating system, ...). We are using the free FIQ interrupt to add our safety code in time-multiplex. Therefore, the CANOpen stack for example uses the API of the standard operating system... No way to add my own API with little effort...

    Any ideas?

    Kind regards and thanks in advance,
    Andreas
Children
No data