target halted due to debug-request

Discussions and support about ChibiStudio, the free development environment for ARM.
Post Reply
jcbless
Posts: 43
Joined: Wed Apr 16, 2025 2:29 pm
Has thanked: 7 times
Been thanked: 3 times

target halted due to debug-request

Post by jcbless »

I am trying to Flash and Run my elf file. However when I do so, I get several "target halted due to debug-request, current mode: Thread" items listed. It is clear that the intended behavior of the code (putting out a pwm wave of 10% and 90% alternatively) is not occurring.

Here is the code:

Code: Select all

/*
    ChibiOS - Copyright (C) 2006..2018 Giovanni Di Sirio

    Licensed under the Apache License, Version 2.0 (the "License");
    you may not use this file except in compliance with the License.
    You may obtain a copy of the License at

        http://www.apache.org/licenses/LICENSE-2.0

    Unless required by applicable law or agreed to in writing, software
    distributed under the License is distributed on an "AS IS" BASIS,
    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    See the License for the specific language governing permissions and
    limitations under the License.
*/

#include "ch.h"
#include "hal.h"
#include "rt_test_root.h"
#include "oslib_test_root.h"

/*
 * This is a periodic thread that does absolutely nothing except flashing
 * a LED.
 */
static THD_WORKING_AREA(waThread1, 128);
static THD_FUNCTION(Thread1, arg) {

  (void)arg;
  chRegSetThreadName("blinker");
  while (true) {
    palSetLine(LINE_LED1);
    chThdSleepMilliseconds(50);
    palSetLine(LINE_LED2);
    chThdSleepMilliseconds(50);
    palSetLine(LINE_LED3);
    chThdSleepMilliseconds(200);
    palClearLine(LINE_LED1);
    chThdSleepMilliseconds(50);
    palClearLine(LINE_LED2);
    chThdSleepMilliseconds(50);
    palClearLine(LINE_LED3);
    chThdSleepMilliseconds(200);
  }
}

static PWMConfig pwmcfg = {
   10000,
   1000,
   NULL,
   {
      {PWM_OUTPUT_ACTIVE_HIGH, NULL},
      {PWM_OUTPUT_ACTIVE_HIGH, NULL},
      {PWM_OUTPUT_ACTIVE_HIGH, NULL},
      {PWM_OUTPUT_ACTIVE_HIGH, NULL}
   },
   0,
   0,
   0
};

/*
 * Application entry point.
 */
int main(void) {

  /*
   * System initializations.
   * - HAL initialization, this also initializes the configured device drivers
   *   and performs the board-specific initializations.
   * - Kernel initialization, the main() function becomes a thread and the
   *   RTOS is active.
   */
  halInit();
  chSysInit();

  pwmStart(&PWMD5, &pwmcfg);

  /*
   * Activates the serial driver 1 using the driver default configuration.
   */
  //sdStart(&SD3, NULL);

  /*
   * Creates the example thread.
   */
  //chThdCreateStatic(waThread1, sizeof(waThread1), NORMALPRIO+1, Thread1, NULL);

  /*
   * Normal main() thread activity, in this demo it does nothing except
   * sleeping in a loop and check the button state.
   */
  while (1) {
    pwmEnableChannel(&PWMD5, 0, PWM_PERCENTAGE_TO_WIDTH(&PWMD5, 1000));   // 10% duty cycle
    pwmEnableChannel(&PWMD5, 1, PWM_PERCENTAGE_TO_WIDTH(&PWMD5, 1000));   // 10% duty cycle
    pwmEnableChannel(&PWMD5, 2, PWM_PERCENTAGE_TO_WIDTH(&PWMD5, 1000));   // 10% duty cycle
    pwmEnableChannel(&PWMD5, 3, PWM_PERCENTAGE_TO_WIDTH(&PWMD5, 1000));   // 10% duty cycle
    chThdSleepMilliseconds(500);
    pwmEnableChannel(&PWMD5, 0, PWM_PERCENTAGE_TO_WIDTH(&PWMD5, 9000));   // 90% duty cycle
    pwmEnableChannel(&PWMD5, 1, PWM_PERCENTAGE_TO_WIDTH(&PWMD5, 9000));   // 90% duty cycle
    pwmEnableChannel(&PWMD5, 2, PWM_PERCENTAGE_TO_WIDTH(&PWMD5, 9000));   // 90% duty cycle
    pwmEnableChannel(&PWMD5, 3, PWM_PERCENTAGE_TO_WIDTH(&PWMD5, 9000));   // 90% duty cycle
    chThdSleepMilliseconds(500);
  }
}


And here is the console text:

Code: Select all

Open On-Chip Debugger 0.11.0+dev-00433-g97db87c22 (2021-10-28-12:22)
Licensed under GNU GPL v2
For bug reports, read
   http://openocd.org/doc/doxygen/bugs.html
Warn : Interface already configured, ignoring
Error: already specified hl_layout stlink
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
srst_only separate srst_nogate srst_open_drain connect_deassert_srst

Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 1800 kHz
Info : STLINK V2J46S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.251968
Info : stm32h7x.cpu0: Cortex-M7 r1p1 processor detected
Info : stm32h7x.cpu0: target has 8 breakpoints, 4 watchpoints
Info : starting gdb server for stm32h7x.cpu0 on 3333
Info : Listening on port 3333 for gdb connections
Info : accepting 'gdb' connection on tcp/3333
target halted due to debug-request, current mode: Thread
xPSR: 0x21000000 pc: 0x08001ea2 psp: 0x200007ec
Info : Device: STM32H74x/75x
Info : flash size probed value 2048
Info : STM32H7 flash has dual banks
Info : Bank (0) size is 1024 kb, base address is 0x08000000
Warn : Prefer GDB command "target extended-remote :3333" instead of "target remote :3333"
target halted due to debug-request, current mode: Thread
xPSR: 0x21000000 pc: 0x08001ea2 psp: 0x200007ec
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080003b8 msp: 0x20000400
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080003b8 msp: 0x20000400
Info : Padding image section 0 at 0x08002b14 with 12 bytes (bank write end alignment)
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080003b8 msp: 0x20000400


Please note that this is being run on a pixhawk 6x pro with Jetson carrier board. I've had to edit board files.

Could you please assist me in finding a solution to this problem? - Thanks, John
User avatar
Giovanni
Site Admin
Posts: 14891
Joined: Wed May 27, 2009 8:48 am
Has thanked: 1202 times
Been thanked: 996 times

Re: target halted due to debug-request

Post by Giovanni »

Hi,

I would suggest to try the same code on some supported nucleo board, this way you can rule out some porting problem. When everything works then you can try the port.

Other suggestions: compile with -O0 for debugging and enable assertions, checks, state checker and stack checker in chconf.h.

Giovanni
jcbless
Posts: 43
Joined: Wed Apr 16, 2025 2:29 pm
Has thanked: 7 times
Been thanked: 3 times

Re: target halted due to debug-request

Post by jcbless »

I've now got the demo code with the dancing LEDs to work on a Nucleo board. It functions properly. Breakpoints function as I'd expect them to when they are placed in the section of code for turning the LEDs on and off. That board has a 753 processor on it, so I use 743 configuration to run it.

The Pixhawk 6x Pro also has a 753 on it, so I tried running the exact same project with the 743 configuration. However, the breakpoints do not function and sometimes the code appears to crash altogether because the buttons for Resume, Suspend, and Terminate all go dim. There are no LEDs that are visible from the outside, so I cannot verify the actual behavior. I haven't even double checked that the LEDs are attached to the same pins between the two boards - there's a good chance they are not. I'm just going off of the breakpoint behavior to determine that it is not working.

I also turned on the -O0 compiler option as well as the various checks you mentioned. Where do I find the outputs from the checks?

Thanks,
John

P.S. - Here's the OpenOCD output:

Code: Select all

Open On-Chip Debugger 0.11.0+dev-00433-g97db87c22 (2021-10-28-12:22)
Licensed under GNU GPL v2
For bug reports, read
   http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
srst_only separate srst_nogate srst_open_drain connect_deassert_srst

Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 1800 kHz
Info : STLINK V2J46S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.255680
Info : stm32h7x.cpu0: Cortex-M7 r1p1 processor detected
Info : stm32h7x.cpu0: target has 8 breakpoints, 4 watchpoints
Info : starting gdb server for stm32h7x.cpu0 on 3333
Info : Listening on port 3333 for gdb connections
Info : accepting 'gdb' connection on tcp/3333
Info : Device: STM32H74x/75x
Info : flash size probed value 2048
Info : STM32H7 flash has dual banks
Info : Bank (0) size is 1024 kb, base address is 0x08000000
Info : Device: STM32H74x/75x
Info : flash size probed value 2048
Info : STM32H7 flash has dual banks
Info : Bank (1) size is 1024 kb, base address is 0x08100000
Warn : Prefer GDB command "target extended-remote :3333" instead of "target remote :3333"
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x08002416 psp: 0x200007e0
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080003b8 msp: 0x20000400
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080003b8 msp: 0x20000400
Info : Padding image section 0 at 0x080160f0 with 16 bytes (bank write end alignment)
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080003b8 msp: 0x20000400
User avatar
Giovanni
Site Admin
Posts: 14891
Joined: Wed May 27, 2009 8:48 am
Has thanked: 1202 times
Been thanked: 996 times

Re: target halted due to debug-request

Post by Giovanni »

Hi,

The checks cause a system halt on failure, after the halt you can break (not stop) the program and look at the stack trace, going backward you will see the assertion/check that caused the halt.

Giovanni
jcbless
Posts: 43
Joined: Wed Apr 16, 2025 2:29 pm
Has thanked: 7 times
Been thanked: 3 times

Re: target halted due to debug-request

Post by jcbless »

At this point, I have explored the behavior more, and most of the time it isn't halting, but rather it is getting stuck on line 276 of hal_lld.c which is:

Code: Select all

  while ((RCC->CR & RCC_CR_HSERDY) == 0)


This is where it is checking that HSE is stable. So it seems that the HSE clock must not be getting stable at all. This led us to think that perhaps there was a hardware problem with our board (Pixhawk 6x Pro mounted on Jetson carrier board). However, we tried reinstalling Ardupilot back on the board to check that the board would run with Ardupilot. It did run.

So we are trying to understand why ChibiOS code is failing to get beyond the check about the clock. Any ideas about why that may be occurring?

Thanks,
John
User avatar
Giovanni
Site Admin
Posts: 14891
Joined: Wed May 27, 2009 8:48 am
Has thanked: 1202 times
Been thanked: 996 times

Re: target halted due to debug-request

Post by Giovanni »

Hi,

Have you created board files for your board? there are settings related to the oscillator, is it a crystal or an external oscillator?

Giovanni
jcbless
Posts: 43
Joined: Wed Apr 16, 2025 2:29 pm
Has thanked: 7 times
Been thanked: 3 times

Re: target halted due to debug-request

Post by jcbless »

I had previously been working with modified board files, but had switched to just using the demo based board files.

Looking through the board files, I'm not seeming to see any settings relating to crystal vs other external oscillators. I may be just not understanding it. What I do see are HSEFrequency and HSEBypass.

Edit: After searching some more it appears that HSEBypass may be what is necessary to indicate an external oscillator other than a crystal oscillator. Is this correct? Today I'm not around my equipment to test.

Thanks,
John
Last edited by jcbless on Sat Oct 04, 2025 8:05 pm, edited 1 time in total.
User avatar
Giovanni
Site Admin
Posts: 14891
Joined: Wed May 27, 2009 8:48 am
Has thanked: 1202 times
Been thanked: 996 times

Re: target halted due to debug-request

Post by Giovanni »

You need HSE Bypass if you have an external oscillator driving the HSE input pin, if you have a crystal then the bypass must be disabled. It is covered in the STM32 RM.

Giovanni
jcbless
Posts: 43
Joined: Wed Apr 16, 2025 2:29 pm
Has thanked: 7 times
Been thanked: 3 times

Re: target halted due to debug-request

Post by jcbless »

Great, when I'm back to the office I'll test this with my equipment.
jcbless
Posts: 43
Joined: Wed Apr 16, 2025 2:29 pm
Has thanked: 7 times
Been thanked: 3 times

Re: target halted due to debug-request

Post by jcbless »

Switching that bit got the demo code to run.

Thanks!
Post Reply