Re: Regarding split images
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 the two newt fixes I mentioned earlier (since merged to master), I am able to build this target. Here is my output: [ccollins@ccollins:~/proj/myproj]$ newt info Repository info: * apache-mynewt-core: 77f75d4bd389d38c3022b815e8684ff49a35ff2f, 0.0.0 * apache-mynewt-nimble: 976bb8f84bf9547efdea444ae79a62d5a355a613, 0.0.0 [ccollins@ccollins:~/proj/myproj]$ newt target show splitty-nrf52dk targets/splitty-nrf52dk app=@apache-mynewt-core/apps/splitty bsp=@apache-mynewt-core/hw/bsp/nordic_pca20020 build_profile=optimized loader=@apache-mynewt-nimble/apps/bleprph syscfg=BLE_LL_CFG_FEAT_LE_ENCRYPTION=0:BLE_SM_LEGACY=0 [ccollins@ccollins:~/proj/myproj]$ newt build splitty-nrf52dk Building target targets/splitty-nrf52dk [...] Target successfully built: targets/splitty-nrf52dk Could you please execute the following two commands and send the output? newt info newt target show Thanks, Chris > > Regards. > > /joseph > > Le mer. 1 mai 2019 à 20:35, Christopher Collins a écrit : > > > Hi Joseph, > > > > On Mon, Apr 29, 2019 at 04:39:50PM +0200, joseph reveane wrote: > > > Hi Chris, > > > > > > I've modified my app setup to point to the nimble repo: > > > > > > *$ newt target show split-apptargets/split-app > > > app=@apache-mynewt-core/apps/splitty > > > bsp=@apache-mynewt-core/hw/bsp/nordic_pca20020 > > > build_profile=optimizedloader=@apache-mynewt-nimble/apps/bleprph > > > syscfg=BLE_LL_CFG_FEAT_LE_ENCRYPTION=0:BLE_SM_LEGACY=0* > > > > > > Then I've treid to build it: > > > > [...] > > > > It seems split image support is indeed broken. I still cannot get the > > same error message as you, but I encountered a different error when I > > tried using your target. > > > > I believe I have fixed this second issue. The PR is here: > > https://github.com/apache/mynewt-newt/pull/295. Could you please give > > it a shot and let me know if it works? > > > > Thanks, > > Chris > >
Re: Adding a callback before asm("bkpt") in the assert function and hal_system_reset()
:) 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 detaches.
You could at least clear that manually at the end of the BSP download script.
Possibly could attempt to clear it in hook-quit with gdb. Doing those 2
things might lessen the likelihood of that bit staying set.
> On 3 May 2019, at 12.41, Vipul Rahane wrote:
>
> 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 debug
> state.
>
> On Fri, May 3, 2019 at 2:37 AM marko kiiskila wrote:
>
>> 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
>>
>> define hook-continue
>> handle SIGALRM pass
>> end
>>
>> If you load this this script in the debug script, these will happen
>> automagically for your BSP. No code changes necessary then,
>> or conditionally compiled code.
>>
>>> On 3 May 2019, at 10.31, 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 about the change
>> itself
>>> so I have few more comments.
>>>
>>> On Fri, May 3, 2019 at 1:57 AM Vipul Rahane wrote:
>>>
Hello,
So, we are running into an issue where some peripheral needs to get shut
down before the breakpoint gets hit. this only happens when the
>> debugger is
connected and so, it quite isolated in terms on functionality.
>>>
>>> It would be better to have such callback/whatever as a general option,
>> not
>>> only while debugger is connected, since this makes it more generic and
>> you
>>> can easily check if debugger is connected in your callback.
>>>
>>>
There are different approaches we could follow:
1. Have a macro (syscfg) define that function and call that macro
154 #ifdef MYNEWT_VAL_HAL_SYSTEM_PRE_BKPT_CB
155HAL_SYSTEM_PRE_BKPT_CB();
156 #endif
157
158 #if !MYNEWT_VAL(MCU_DEBUG_IGNORE_BKPT)
159asm("bkpt");
160 #endif
2. Have a `hal_system_pre_bkpt_cb()` function, register a callback and
>> have
one specific MCU call it only if a syscfg is set, something like:
154 #ifdef MYNEWT_VAL(HAL_SYSTEM_PRE_BKPT_CB)
155hal_system_pre_bkpt_cb();
156 #endif
157
158 #if !MYNEWT_VAL(MCU_DEBUG_IGNORE_BKPT)
159asm("bkpt");
160 #endif
>>>
>>> I am not a fan of injecting code via syscfg, so definitely would prefer
>>> callback approach or just have a function declaraction that application
>>> should define if those callbacks are enabled. - this is quite low level
>> API
>>> so user-friendliness of a callbacks is not something I'd require, but
>> otoh
>>> there may be some scenarios where callbacks could be useful (I don't have
>>> anything specific in mind).
>>>
>>> Also refering to what was done in PR, I do not think that having a single
>>> syscfg defined in MCU which controls code in both hal_system and
>> kernel/os
>>> is a good idea. I'd prefer separate options for callback in
>>> hal_system_reset (like MCU_PRE_RESET_CALLBACK) and __assert_func (like
>>> OS_ASSERT_CALLBACK).
>>>
>>> These are just some simple suggestions we could follow, obviously there
>> is
a hard way of doing this thing where we change APIs and register a
>> callback
and have assert take that callback as an argument but I am not a big
>> fan of
changing standard APIs.
If others have a suggestion, please let me know. If not I am going to
assume everybody is fine with option 2.
--
Regards,
Vipul Rahane
>>>
>>> Best,
>>> Andrzej
>
>
> Regards,
> Vipul Rahane
>
>>
>>
>> --
>
> Regards,
> Vipul Rahane
Re: Adding a callback before asm("bkpt") in the assert function and hal_system_reset()
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 about the change itself
> so I have few more comments.
>
> On Fri, May 3, 2019 at 1:57 AM Vipul Rahane wrote:
>
> > Hello,
> >
> > So, we are running into an issue where some peripheral needs to get shut
> > down before the breakpoint gets hit. this only happens when the debugger
> is
> > connected and so, it quite isolated in terms on functionality.
> >
>
> It would be better to have such callback/whatever as a general option, not
> only while debugger is connected, since this makes it more generic and you
> can easily check if debugger is connected in your callback.
>
>
> > There are different approaches we could follow:
> >
> > 1. Have a macro (syscfg) define that function and call that macro
> >
> > 154 #ifdef MYNEWT_VAL_HAL_SYSTEM_PRE_BKPT_CB
> > 155HAL_SYSTEM_PRE_BKPT_CB();
> > 156 #endif
> > 157
> > 158 #if !MYNEWT_VAL(MCU_DEBUG_IGNORE_BKPT)
> > 159asm("bkpt");
> > 160 #endif
> >
> > 2. Have a `hal_system_pre_bkpt_cb()` function, register a callback and
> have
> > one specific MCU call it only if a syscfg is set, something like:
> >
> > 154 #ifdef MYNEWT_VAL(HAL_SYSTEM_PRE_BKPT_CB)
> > 155hal_system_pre_bkpt_cb();
> > 156 #endif
> > 157
> > 158 #if !MYNEWT_VAL(MCU_DEBUG_IGNORE_BKPT)
> > 159asm("bkpt");
> > 160 #endif
> >
>
> I am not a fan of injecting code via syscfg, so definitely would prefer
> callback approach or just have a function declaraction that application
> should define if those callbacks are enabled. - this is quite low level API
> so user-friendliness of a callbacks is not something I'd require, but otoh
> there may be some scenarios where callbacks could be useful (I don't have
> anything specific in mind).
>
> Also refering to what was done in PR, I do not think that having a single
> syscfg defined in MCU which controls code in both hal_system and kernel/os
> is a good idea. I'd prefer separate options for callback in
> hal_system_reset (like MCU_PRE_RESET_CALLBACK) and __assert_func (like
> OS_ASSERT_CALLBACK).
>
> These are just some simple suggestions we could follow, obviously there is
> > a hard way of doing this thing where we change APIs and register a
> callback
> > and have assert take that callback as an argument but I am not a big fan
> of
> > changing standard APIs.
> >
> > If others have a suggestion, please let me know. If not I am going to
> > assume everybody is fine with option 2.
> >
> > --
> >
> > Regards,
> > Vipul Rahane
> >
>
> Best,
> Andrzej
>
--
Regards,
Vipul Rahane
Re: Adding a callback before asm("bkpt") in the assert function and hal_system_reset()
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 debug
state.
On Fri, May 3, 2019 at 2:37 AM marko kiiskila wrote:
> 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
>
> define hook-continue
> handle SIGALRM pass
> end
>
> If you load this this script in the debug script, these will happen
> automagically for your BSP. No code changes necessary then,
> or conditionally compiled code.
>
> > On 3 May 2019, at 10.31, 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 about the change
> itself
> > so I have few more comments.
> >
> > On Fri, May 3, 2019 at 1:57 AM Vipul Rahane wrote:
> >
> >> Hello,
> >>
> >> So, we are running into an issue where some peripheral needs to get shut
> >> down before the breakpoint gets hit. this only happens when the
> debugger is
> >> connected and so, it quite isolated in terms on functionality.
> >>
> >
> > It would be better to have such callback/whatever as a general option,
> not
> > only while debugger is connected, since this makes it more generic and
> you
> > can easily check if debugger is connected in your callback.
> >
> >
> >> There are different approaches we could follow:
> >>
> >> 1. Have a macro (syscfg) define that function and call that macro
> >>
> >> 154 #ifdef MYNEWT_VAL_HAL_SYSTEM_PRE_BKPT_CB
> >> 155HAL_SYSTEM_PRE_BKPT_CB();
> >> 156 #endif
> >> 157
> >> 158 #if !MYNEWT_VAL(MCU_DEBUG_IGNORE_BKPT)
> >> 159asm("bkpt");
> >> 160 #endif
> >>
> >> 2. Have a `hal_system_pre_bkpt_cb()` function, register a callback and
> have
> >> one specific MCU call it only if a syscfg is set, something like:
> >>
> >> 154 #ifdef MYNEWT_VAL(HAL_SYSTEM_PRE_BKPT_CB)
> >> 155hal_system_pre_bkpt_cb();
> >> 156 #endif
> >> 157
> >> 158 #if !MYNEWT_VAL(MCU_DEBUG_IGNORE_BKPT)
> >> 159asm("bkpt");
> >> 160 #endif
> >>
> >
> > I am not a fan of injecting code via syscfg, so definitely would prefer
> > callback approach or just have a function declaraction that application
> > should define if those callbacks are enabled. - this is quite low level
> API
> > so user-friendliness of a callbacks is not something I'd require, but
> otoh
> > there may be some scenarios where callbacks could be useful (I don't have
> > anything specific in mind).
> >
> > Also refering to what was done in PR, I do not think that having a single
> > syscfg defined in MCU which controls code in both hal_system and
> kernel/os
> > is a good idea. I'd prefer separate options for callback in
> > hal_system_reset (like MCU_PRE_RESET_CALLBACK) and __assert_func (like
> > OS_ASSERT_CALLBACK).
> >
> > These are just some simple suggestions we could follow, obviously there
> is
> >> a hard way of doing this thing where we change APIs and register a
> callback
> >> and have assert take that callback as an argument but I am not a big
> fan of
> >> changing standard APIs.
> >>
> >> If others have a suggestion, please let me know. If not I am going to
> >> assume everybody is fine with option 2.
> >>
> >> --
> >>
> >> Regards,
> >> Vipul Rahane
> >>
> >
> > Best,
> > Andrzej
Regards,
Vipul Rahane
>
>
> --
Regards,
Vipul Rahane
Re: Adding a callback before asm("bkpt") in the assert function and hal_system_reset()
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
define hook-continue
handle SIGALRM pass
end
If you load this this script in the debug script, these will happen
automagically for your BSP. No code changes necessary then,
or conditionally compiled code.
> On 3 May 2019, at 10.31, Andrzej Kaczmarek
> wrote:
>
> Hi,
>
> I already put some of comments below in (already merged) PR which seems to
> add this functionality, but this gives more context about the change itself
> so I have few more comments.
>
> On Fri, May 3, 2019 at 1:57 AM Vipul Rahane wrote:
>
>> Hello,
>>
>> So, we are running into an issue where some peripheral needs to get shut
>> down before the breakpoint gets hit. this only happens when the debugger is
>> connected and so, it quite isolated in terms on functionality.
>>
>
> It would be better to have such callback/whatever as a general option, not
> only while debugger is connected, since this makes it more generic and you
> can easily check if debugger is connected in your callback.
>
>
>> There are different approaches we could follow:
>>
>> 1. Have a macro (syscfg) define that function and call that macro
>>
>> 154 #ifdef MYNEWT_VAL_HAL_SYSTEM_PRE_BKPT_CB
>> 155HAL_SYSTEM_PRE_BKPT_CB();
>> 156 #endif
>> 157
>> 158 #if !MYNEWT_VAL(MCU_DEBUG_IGNORE_BKPT)
>> 159asm("bkpt");
>> 160 #endif
>>
>> 2. Have a `hal_system_pre_bkpt_cb()` function, register a callback and have
>> one specific MCU call it only if a syscfg is set, something like:
>>
>> 154 #ifdef MYNEWT_VAL(HAL_SYSTEM_PRE_BKPT_CB)
>> 155hal_system_pre_bkpt_cb();
>> 156 #endif
>> 157
>> 158 #if !MYNEWT_VAL(MCU_DEBUG_IGNORE_BKPT)
>> 159asm("bkpt");
>> 160 #endif
>>
>
> I am not a fan of injecting code via syscfg, so definitely would prefer
> callback approach or just have a function declaraction that application
> should define if those callbacks are enabled. - this is quite low level API
> so user-friendliness of a callbacks is not something I'd require, but otoh
> there may be some scenarios where callbacks could be useful (I don't have
> anything specific in mind).
>
> Also refering to what was done in PR, I do not think that having a single
> syscfg defined in MCU which controls code in both hal_system and kernel/os
> is a good idea. I'd prefer separate options for callback in
> hal_system_reset (like MCU_PRE_RESET_CALLBACK) and __assert_func (like
> OS_ASSERT_CALLBACK).
>
> These are just some simple suggestions we could follow, obviously there is
>> a hard way of doing this thing where we change APIs and register a callback
>> and have assert take that callback as an argument but I am not a big fan of
>> changing standard APIs.
>>
>> If others have a suggestion, please let me know. If not I am going to
>> assume everybody is fine with option 2.
>>
>> --
>>
>> Regards,
>> Vipul Rahane
>>
>
> Best,
> Andrzej
