• Locked Locked
  • Replies 5 replies
  • Subscribers 119 subscribers
  • Views 3486 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
  • 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
  • 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
  • Note: This was originally posted on 6th October 2009 at http://forums.arm.com

    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.

    You could of course decode the instruction to obtain the source register and compare the bitmask...
    Seriously what I am thinking of is a lot easier. The data abort handler will only take care of the appropriate error handling whatever that is in your system.

    As long as you distinguish between critical and non-critical parts of your design (e.g. privileges, domains), there will be a way to determine whether a function has been called from either side. Let's just assume that your critical system components are privileged. Let's further assume that your page table denies unprivileged access to the GPIO device. Rogue code won't be able to access GPIO directly, due to access permissions. Device access is implemented as SVC which checks where it has been called from (SPSR) and matches a bit mask of safe/non-safe GPIO.
    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...

    Which doesn't stop you from using a function similar to the one described above. You could adapt this for other devices.

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

    I don't think what you want to do is possible.  The core can be configurred to generate aborts on watch point hits (Monitor Mode Debug).  However, the watch point won't hit until the memory stage of the pipeline.  So after the access has been committed.