Trouble programming Arm Cortex M0 (stuck in the reset_handler)

In summary: Debuggers can often interfere with the main program -- I only run them if I have to in order to debug a problem. As jedi asks -- does your program run normally without the debugger overhead?Alternatively, can you strip this program down to bare bones to see if that will run? If it runs, slowly build it back up to see what breaks it. If not, you must have something wrong with your build/run environment, IMO...
  • #1
core7916
62
3
TL;DR Summary
programming arm m0
Hello,
i am programming pga970evm module and the core is of arm cortex m0. the program what i have is building succesfully , but while debugging it is stuck or halting in reset (reset_handler) and not comming out of it (startup code).
i will provide screen shot of debug page.

another thing is i cant access the breakpoints while debugging. while begugging i came to know that controller is not calling the main function since it is not comming out of reset state.
IMG-20230215-WA0005.jpg


as shown in image the reset is happening at resetisr() function(startup code). if i again resume the debug it will continuously stays in same state(reset). i cant share the full code. i have included all necessary files which is required to run.
1. please can you tell me what may cause the micro controller to halt in reset state.?
2. why i cant aces the breakpoints ?
3. in xPSR i am getting exception as 010000 . does this is the reason i am getting this?
Thank you.
 
Technology news on Phys.org
  • #2
Does the code work when running normally? Perhaps debugging interferes with doing resets.

Have you searched the web for answers? A vendor forum specializing in this processor would be a better place to ask this question.
 
  • #3
jedishrfu said:
Does the code work when running normally? Perhaps debugging interferes with doing resets.

Have you searched the web for answers? A vendor forum specializing in this processor would be a better place to ask this question.
hello i already searched in web for this problem and contacted vendors. Their ans were not usefull. I will atach one zip file in which it shows how controller behaves when i am debugging.Please suggest any solutions.
Thank you.
 
  • #4
core7916 said:
I will atach one zip file
I'm not sure the PF software will let you upload a ZIP file. Even if it does, it would be bad practice for us to download and unzip it... PDF screenshots are safer.
 
  • #5
Also I doubt we can help much here.

We are not experts with this particular device and to run your code, we'd have to install the tools, your code, your hardware and try to reproduce the error. This is why we ask developers to diagnose the problem themselves.
 
Last edited:
  • Like
Likes Vanadium 50 and berkeman
  • #6
@core7916 -- What is your experience level so far programming this uP? Have you successfully run many projects in the past, and this is the first one giving you trouble? Or is this your first project on an Arm M0?

jedishrfu said:
Does the code work when running normally? Perhaps debugging interferes with doing resets.
Debuggers can often interfere with the main program -- I only run them if I have to in order to debug a problem. As jedi asks -- does your program run normally without the debugger overhead?

Alternatively, can you strip this program down to bare bones to see if that will run? If it runs, slowly build it back up to see what breaks it. If not, you must have something wrong with your build/run environment, IMO...
 
  • #7
jedishrfu said:
Does the code work when running normally? Perhaps debugging interferes with doing resets.

Have you searched the web for answers? A vendor forum specializing in this processor would be

berkeman said:
@core7916 -- What is your experience level so far programming this uP? Have you successfully run many projects in the past, and this is the first one giving you trouble? Or is this your first project on an Arm M0?Debuggers can often interfere with the main program -- I only run them if I have to in order to debug a problem. As jedi asks -- does your program run normally without the debugger overhead?

Alternatively, can you strip this program down to bare bones to see if that will run? If it runs, slowly build it back up to see what breaks it. If not, you must have something wrong with your build/run environment, IMO...
this is the first project i am working with microcontroller . my coding level is not good. but i am not doubting the code since i got the code from vendors. i didnt made changes to code. i am just giving the breakpoints and trying to observe what is happening inside of controller, which i cant due to above problem(reset).
 
  • #8
Do you have the watchdog enabled? The debugger often does not stop it so you have to disable before debugging or you get a reset soon after a breakpoint.

BoB
 
  • Like
Likes berkeman
  • #9
rbelli1 said:
Do you have the watchdog enabled? The debugger often does not stop it so you have to disable before debugging or you get a reset soon after a breakpoint.

BoB
sir, i have already disabled the watchdog timer and tried to debug, still results are same.
 
  • #10
You mentioned using stock vendor code for this work. Try searching using a portion of the stock vendor code + using the debugger with this code maybe someone will have run into the same issue. So far, PF posters aren't coming up with anything helpful to your problem.
 
  • #11
jedishrfu said:
You mentioned using stock vendor code for this work. Try searching using a portion of the stock vendor code + using the debugger with this code maybe someone will have run into the same issue. So far, PF posters aren't coming up with anything helpful to your problem.
thank you for you reply , i already contacted venders about these issue but not useful with their answers.
 
  • #12
I have not used that processor but here are a few ideas:

First, check that the RESET input pin is not asserted! AND that there is not any electrical noise on it.

In the User Manual at:
https:\\www.renesas.com\document\man\idt-arm-cortex-m0-user-guide
See on:
pg 12, sec. 2.2.1.3.4 Program Counter (PC)
pg 94, sec. 2.4.2.4 Application Interrupt and Reset Control Register (AIRCR) and table references contained there-in.

(above user guide was the 4th listed by Google search: arm cortex m0 manual,
the PDF manual was then searched for: reset)

Hope this helps!

Cheers,
Tom
 
  • Like
Likes jedishrfu

FAQ: Trouble programming Arm Cortex M0 (stuck in the reset_handler)

Why am I having trouble programming my Arm Cortex M0 and getting stuck in the reset_handler?

One common reason for this issue is that the reset handler code is not properly set up in the startup file or linker script. Make sure that the reset handler is defined correctly and that the vector table is pointing to the right address.

How can I troubleshoot being stuck in the reset_handler when programming my Arm Cortex M0?

One approach is to check the initialization code for the microcontroller, including the clock configuration and peripheral initialization. Additionally, debugging tools like a debugger or serial console can help identify the specific point of failure in the reset_handler code.

Is there a specific pattern of errors that indicate being stuck in the reset_handler on an Arm Cortex M0?

Common indicators of being stuck in the reset_handler include the program not progressing past the reset vector, the microcontroller not responding to debug commands, or the program repeatedly resetting without executing any application code.

What are some common pitfalls to avoid when programming an Arm Cortex M0 to prevent getting stuck in the reset_handler?

Avoid common pitfalls like incorrect clock configuration, incorrect memory mapping, incorrect vector table setup, or incorrect linker script configuration. Double-checking these settings can help prevent issues with the reset_handler.

Are there any resources or tools available to help troubleshoot being stuck in the reset_handler on an Arm Cortex M0?

There are various resources available, such as forums, online communities, and documentation provided by the microcontroller manufacturer. Additionally, using debugging tools like JTAG/SWD debuggers or integrated development environments (IDEs) can help diagnose and resolve issues with the reset_handler.

Back
Top