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

Cortext M3 Program Counter Test

Note: This was originally posted on 16th March 2011 at http://forums.arm.com

I am working with Cortex M3 and want to perfrom Stuck at (To check that none of the bit of PC is stuck at 0 or 1) test of Program Counter. Can anybody give me an idea how to implement this? Thanks in advance!
  • Note: This was originally posted on 21st March 2011 at http://forums.arm.com

    The device has MPU. I have actually figured out that it can be done by placing code (short subroutine) at 0x55..... and 0xAA..... locations in memory and then reading that location to verfiy whether the program counter has reached that particular locations. Now I have checkd that the memory locations (On chip SRAM, Code SRAM and Flash) are occupied with different types of code. At some memory locations I found ff pattern and on the others random patterns. Some locations were writeable others were not. I am confused, where how to select the area, which I want to write. If someone knows about some document or link that describe working with Cortex M3 memory specfically or any other generally, please let me know or just give me a hint here.
    Thanks
    ahsan


    Does your device have an MPU?
    --
    Marcus
  • Note: This was originally posted on 18th March 2011 at http://forums.arm.com

    Does your device have an MPU?
    --
    Marcus
  • Note: This was originally posted on 21st March 2011 at http://forums.arm.com

    How about a sequence of 16bit instructions (minimum of 16), at a 32 byte aligned address. An appropriate choice of instructions will expose stuck-at faults in the lower bits of PC. For the upper bits you might want to use MPU regions marked as NX, which cover the address you want to verify. The MemManange Fault will tell you whether you've actually tried to access that address.
    Depending on the requirements it may be sufficient if only the MPU sees the address. If you want to check actual address bits on the instruction interface, you'll have to find a more complex approach.

    Regards
    Marcus