• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 874 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RM46L852: How to know which the cpu is in debug mode or not

user4975967
Prodigy 110 points

Part Number: RM46L852

I would like to know which the CPU is in debug mode by connecting JTAG, or not.

I know when JTAG is attached, nTRST signal goes to high, but I could not find how to know which the nTRST signal is high or low by any register of CPU, or something like that.

  • 0
    TI__Guru 59540 points
    Hello User,

    This is described in the ARM Cortec R4F TRM on the ARM web site since the Debug unit is part of the CPU/ARM IP. Information on the Debug controller can be found at this link infocenter.arm.com/.../index.jsp in chapter 11. In particular, I believe you will be interested in section 11.8 which discussed the Debug State information.

    In general we recommend using the ARM corsight debug capability to disable the debug logic via the 4-bit key or to use the AJSM to void intrusions via the JTAG port during runtime. See section 7.133 7.135 of the Safety Manual for further details on these recommendations.
  • 0 in reply to Chuck Davenport
    Prodigy 110 points

    Dear Chuck,

    Thank you for your reply.

    When I have read DSCR register after ICE(Blackhawk)  has attached in our custom board, DSCR[0] was not set.

    Otherwise, only DSCR[14] (Hating mode) was set.

    My test step is as follows:

    1. Connect ICE  to our board.

    2. Power on.

    3. Reset CPU by ICE.

    4. Read DSCR register in startup routine, and store the value of the register in an address.

    5. Read the value of the address.

    Could you let me know the correct way to  read DSCR when  DSCR[0] is set?

    Best Regards,

    Shigeru Maeda

  • 0 in reply to user4975967
    TI__Guru 59540 points
    Hello Shigero-san,

    Bit 14 is only to indicate that halting mode is enabled not that it has been halted. Bit 0 will indicate if the CPU has been halted in debug state but it will only be able to be seen by the host in the system since this bit will only be set when the CPU is halted.

    I have consulted with one of our Cortex-R4/R5 experts and they have indicated that there is no memory mapped location to determine debug state during run time.

    Is there a specific reason you are looking for this functionality? I am interested in case we can offer either further explanation or evaluate if there is a potential for an alternative solution.
  • 0 in reply to Chuck Davenport
    Prodigy 110 points

    Hello Chuck,

    We have to change our firmware whether ICE is attached to our board or not, because when ICE is attached we have to run maintainance firmware on the board except for normal firmaware.

    The sequence is as follows:

    1. Power on our board

    2. If ICE is attached then run the maintainance firmaware, else normal firmware.

    Best Regards,

    Shigeru Maeda

  • 0 in reply to user4975967
    TI__Guru 59540 points
    Hello Shigeru-san,

    My apologies for the delay in getting back with you. In your ICE implementation, is there any other forms of communication other than JTAG? i.e., can you have the ICE send a special command over SPI, UART, or CAN that would cause the device to branch to your maintenance Firmware? Another method that might work, would be to use a special combination of IO pin states that is unrealistic to occur in your normal operation to cause the firmware to branch to the maintenance mode. If you follow this second method, for certain there would need to be multiple bits/pins involved to prevent a single fault from instantiating the maintenance firmware in the field.