Do ARM Jtag pins need configuring?

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
  • 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
  • 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
More questions in this forum
There are no posts to show. This could be because there are no posts in this forum or due to a filter.