• State Suggested Answer
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 22 subscribers
  • Views 5011 views
  • Users 0 members are here
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

Do ARM Jtag pins need configuring?

bptsj

I'm debugging an issue on an STM32G431 (32bit M4 core) where when I start a motor the debugger crashes. By crashing I mean all windows turn to garbage and I no longer have debugger control of the MCU. Before I start the motor the JTAG runs fine and displays and updates windows as I would expect.

My question is do the five JTAG lines need any special configuring? I read in ref manual that after reset they come up in a mode to operate as JTAG pins so I am not doing anything with them in the code. Also, I do not have any external pull-ups or pull downs, as the reference manual says this is done in the MCU.

Do these pins need to be 'locked' so that other code cannot accidently change the configuration or write to them?

I am using Keil MDK5 latest version and the Segger J-Link EDU with latest drivers.

Thanks for your help,

Brian

Parents
  • 0

    Hi Brian,

    I am not directly familiar with this device, but the symptoms you describe are typical of a locked system, whereby a memory access never returns and so the system is stuck in the middle of an instruction execution (a data abort would be a meaningful return), and so the debugger cannot regain control.

    Unfortunately deciphering the cause will likely not be easy. I recommend setting a number of breakpoints to see how far into the code you get before this issue occurs - the issue could be anything from a read from a peripheral that does not respond, or perhaps a stack or heap overflow (though these often will result in data aborts, which would not lock the system)

    You may wish to post your question to the STM32 forum if you have not already:

    https://community.st.com/s/topic/0TO0X000000BSqSWAW/stm32-mcus

    Regards, Ronan

Reply
  • 0

    Hi Brian,

    I am not directly familiar with this device, but the symptoms you describe are typical of a locked system, whereby a memory access never returns and so the system is stuck in the middle of an instruction execution (a data abort would be a meaningful return), and so the debugger cannot regain control.

    Unfortunately deciphering the cause will likely not be easy. I recommend setting a number of breakpoints to see how far into the code you get before this issue occurs - the issue could be anything from a read from a peripheral that does not respond, or perhaps a stack or heap overflow (though these often will result in data aborts, which would not lock the system)

    You may wish to post your question to the STM32 forum if you have not already:

    https://community.st.com/s/topic/0TO0X000000BSqSWAW/stm32-mcus

    Regards, Ronan

Children