• 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 5th October 2009 at http://forums.arm.com

    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.

    Unlike ARM11 and later cores, ARM926 cp14 allows rather limited access to debug logic.

    Either way, I would stay away from such kludges especially in safety critical applications. Remember that for each hardware feature, you have to verify that it actually behaves as expected. As soon as you connect a JTAG adapter, things won't work as expected as the debug tool might overwrite your settings.

    How about making GPIO only accessible from safety code? An appropriate API for accessing safety implementations of the GPIO set/clear functions would be exported. These functions would then verify (compare with bit mask of safe/normal GPIO pins) whether an access is valid (called from safety code) or not (called from normal code).

    Best regards
    Marcus
Reply
  • Note: This was originally posted on 5th October 2009 at http://forums.arm.com

    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.

    Unlike ARM11 and later cores, ARM926 cp14 allows rather limited access to debug logic.

    Either way, I would stay away from such kludges especially in safety critical applications. Remember that for each hardware feature, you have to verify that it actually behaves as expected. As soon as you connect a JTAG adapter, things won't work as expected as the debug tool might overwrite your settings.

    How about making GPIO only accessible from safety code? An appropriate API for accessing safety implementations of the GPIO set/clear functions would be exported. These functions would then verify (compare with bit mask of safe/normal GPIO pins) whether an access is valid (called from safety code) or not (called from normal code).

    Best regards
    Marcus
Children
No data