Question over SIGTRAP Breakpoint at mbed-os\platform/mbed_semihost_api.h:50

[Hecatron]

Note: This is just a template, so feel free to use/remove the unnecessary things

Description

• Type: Question
• Priority: Minor

---

Question

Target LPC1768 Toolchain: GCC_ARM Toolchain version: 7 2017-q4-major mbed-cli version: 1.4.0

Question

Hi, I've been experimenting debugging mbed code using Visual Studio Code, and Cortex-M GDB Plugin Along with a JLink Segger

For the following board (which is a LPC1769)

• https://www.embeddedartists.com/products/lpcxpresso/lpc1769_cmsis_xpr.php

So far I've gotten everything working but when calling the wait function, the code breakpoints at the following without a breakpoint being set which makes debugging code difficult

Program
 received signal SIGTRAP, Trace/breakpoint trap.
0x00000e38 in __semihost () at .\mbed-os\platform/mbed_semihost_api.h:50
50      asm volatile (

Even though no breakpoint is set

If I disable the RTOS by adding the following to .mbedignore

mbed-os/rtos/*
mbed-os/features/FEATURE_CLIENT/*
mbed-os/features/FEATURE_COMMON_PAL/*
mbed-os/features/FEATURE_UVISOR/*
mbed-os/features/FEATURE_LWIP/*
mbed-os/features/frameworks/*
mbed-os/features/net/*
mbed-os/features/netsocket/*
mbed-os/features/storage/*
mbed-os/events/*

This avoids the breakpoint for simple code with out the rtos I'm wondering if this is associated with DEVICE_SEMIHOST, which seems to be defined.

my local .mbed config file btw is

ROOT=.
TARGET=LPC1768
TOOLCHAIN=GCC_ARM
GCC_ARM_PATH=C:\Program Files (x86)\GNU Tools ARM Embedded\7 2017-q4-major\bin

[Hecatron]

Just to update on this one I think this is more of a bug, than a question I've noticed with RTOS enabled the device just locks up on wait with a breakpoint without a breakpoint ever being set or listed within gdb

The cause seems to be something within the below which when included (not excluded from .mbedignore) causes the lockup

mbed-os/rtos/*

I also have to exclude

mbed-os/features/FEATURE_LWIP/*
mbed-os/features/frameworks/*
mbed-os/features/netsocket/*

since they depend on rtos

Openocd gdb debugging

I recently managed to debug via openocd and got some different results about the breakpoint than the segger Jlink

Openocd console

Polling target lpc17xx.cpu failed, trying to reexamine
Info : lpc17xx.cpu: hardware has 6 breakpoints, 4 watchpoints
Error: lpc17xx.cpu -- clearing lockup after double fault

VSCode Debug Console

lpc17xx.cpu -- clearing lockup after double fault
Program
 received signal SIGINT, Interrupt.
osRegisterForOsEvents (observer=0x100024c4 <env_mutex_obj>) at ../../mbed-os\rtos\TARGET_CORTEX\rtx5\RTX\Source\rt_OsEventObserver.c:43
43  {

Call stack

osRegisterForOsEvents@0x00000000 (d:\SourceControl\GitRepos\GBD.Dlang.MbedBlinkyTest\mbed-os\rtos\TARGET_CORTEX\rtx5\RTX\Source\rt_OsEventObserver.c:43)
<signal handler called>@0xfffffff1 (Unknown Source:0)
osRegisterForOsEvents@0x00000000 (d:\SourceControl\GitRepos\GBD.Dlang.MbedBlinkyTest\mbed-os\rtos\TARGET_CORTEX\rtx5\RTX\Source\rt_OsEventObserver.c:43)
<signal handler called>@0xfffffff9 (Unknown Source:0)
__svcKernelInitialize@0x00002408 (d:\SourceControl\GitRepos\GBD.Dlang.MbedBlinkyTest\mbed-os\rtos\TARGET_CORTEX\rtx5\RTX\Source\rtx_kernel.c:69)
osKernelInitialize@0x00002408 (d:\SourceControl\GitRepos\GBD.Dlang.MbedBlinkyTest\mbed-os\rtos\TARGET_CORTEX\rtx5\RTX\Source\rtx_kernel.c:510)
software_init_hook@0x000019c2 (d:\SourceControl\GitRepos\GBD.Dlang.MbedBlinkyTest\mbed-os\rtos\TARGET_CORTEX\mbed_boot.c:567)
_start@0x0000036e (Unknown Source:0)
_start@0x0000036e (Unknown Source:0)

[Mirrored to Jira]

[0xc0170]

Your target uses semihosting. Did you enable it in the openocd of jlink gdb? Shouldn't this be set monitor semihosting enable ? [Mirrored to Jira]

[Hecatron]

so far I've tried under openocd "monitor arm semihosting enable" and it's shown as enabled in the logs but that's still breakpointing within rt_OsEventObserver.c on OsRegisterForOsEvents

For JLink I tried "monitor semihosting enable" and the logs confirm it's enabled but it still forces a breakpoint, with the following in the console

unknown stop reply packet: W58thread:0000dead;

continuing is impossible at this point

I might try the master version of mbed to see if that fixes it [Mirrored to Jira]

[Hecatron]

I wonder if this is because I'm using a LPC1769 with the LPC1768 target Edit, nope still the same [Mirrored to Jira]

[0xc0170]

Is it related to the sleep ? With rtos, idle loop goes to sleep. Please review hal_sleep function for your target.

From what I read, it does mbed_interface_disconnect if semihost is defined, this might explain the failures you are seeing? [Mirrored to Jira]

[Hecatron]

It seems to be related to the Thread:Wait I think. I initially tried it without semihosting, then with semihosting afterwards. I'll be getting a different ST based board in a couple of days to try the same thing out with (a ST NUCLEO-F767ZI) this should tell me if it's something specific to that target [Mirrored to Jira]

[Hecatron]

I just tried a NUCLEO-F767ZI (STM32) and this doesn't have this problem so it seems to be something specific to the LPC1769

I noticed an error when trying to debug the LPC1769 from the Segger JLink which was interesting "unsupported semihosting functionality (R0 = 0x105)" (semihosting was enabled btw)

Since I'll be using STM32's from now on anyways I'm not too fussed but I figured someone else might find this interesting if they're using an LPC device [Mirrored to Jira]

[0xc0170]

@ARMmbed/team-nxp [Mirrored to Jira]

[adbridge]

Internal Jira reference: https://jira.arm.com/browse/IOTPART-5642

[ciarmcom]

Thank you for raising this issue. Please note we have updated our policies and now only defects should be raised directly in GitHub. Going forward questions and enhancements will be considered in our forums, https://forums.mbed.com/ . If this issue is still relevant please re-raise it there. This GitHub issue will now be closed.