On Thu, May 02, 2019 at 11:05:11AM +0200, joseph reveane wrote:
> Hi Chris,
>
> I've just tried your latest fix and I still get the same error:
>
> *Error: Two app packages in build: apps/splitty, apps/bleprph*
Huh... I am really not sure. I believe I am using the same target as
you. Using
:) It would not, as in that scenario there is no gdb context to execute these.
If C_DEBUGEN bit in the Debug Halting Control and Status Register (DHCSR)
is not cleared on debugger detach, I don’t think firmware can do it either.
It’s JLink/openocd which is supposed to clear this when it
Hi,
Yes, I got your input and will try to factor it in.
- Vipul
On Fri, May 3, 2019 at 12:32 AM Andrzej Kaczmarek <
andrzej.kaczma...@codecoup.pl> wrote:
> Hi,
>
> I already put some of comments below in (already merged) PR which seems to
> add this functionality, but this gives more context
Hi Marko,
Exactly what I was thinking just did not know how to do it but there was
one hiccup with this approach. Would this work when the device is not
physically connected to the debugger but was previously connected to the
debugger but still keeps thinking that it was since the MCU is in the
You can execute stuff within gdb when it hits a breakpoint.
function hook-stop gets called when you stop in debugger.
hook-run and hook-continue execute if you ‘run’ or ‘continue’ from
debugger, respectively.
define hook-stop
handle SIGALRM nopass
end
define hook-run
handle SIGALRM pass
end
