You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by amit mehta <gm...@gmail.com> on 2017/03/29 21:31:09 UTC

Query on application: Bare metal or using Mynewt RTOS

Based on the following (see below), my understanding is that any
simple application such as a blinky, which does not explicitly create
tasks (e.g. by calling os_task_init), is still runs as an application and
is taken care by the Mynewt RTOS, i.e. It's not a bare metal application
Reasons are:

1: syscfg.yml:
The application configuration, reported by newt seem to suggest
that there the image that would be build will have an OS. Logs below:

<snip from target list>
$ newt target show
targets/my_blinky
    app=apps/blinky
    bsp=@apache-mynewt-core/hw/bsp/nrf52dk
    build_profile=optimized
<snip from target list>

<snip from blinky(my_blinky) configuration>
$ newt target config show my_blinky
  * Setting: OS_SCHEDULING
    * Description: Whether OS will be started or not
    * Value: 1 <--
...
...
* PACKAGE: sys/sysinit
  * Setting: SYSINIT_CONSTRAIN_INIT
    * Description: Only allow packages to be initialized by sysinit.
    * Value: 1 <---

<snip from blinky(my_blinky) configuration>

There is no syscfg.yml file under the package (apps/blinky directory)
to override (If It would have been overriden, it would show up in the
above log as well)

2: The symbols in the ELF file generated by the build system also
has OS related code symbols. logs below:

<snip from nm>
$ pwd
~/bin/targets/my_blinky/app/apps/blinky

$ arm-none-eabi-nm blinky.elf | grep -i os_
200022d8 B g_hal_os_tick
20002300 B g_os_cputime
20001184 b g_os_dev_list
200020dc B g_os_idle_ctr
200021fc B g_os_last_ctx_sw_time
20000100 D g_os_mempool_list
200000e8 D g_os_run_list
20001f78 B g_os_sanity_check_list
200021ec B g_os_sanity_check_mu
200000f0 D g_os_sleep_list
200021e0 B g_os_started
20002200 B g_os_task_list
2000220c B g_os_time
00009b4e t nrf52_os_tick_counter.part.0
00009b8c t nrf52_os_tick_set_ocmp
00008e7c T os_arch_ctx_sw
00008ea2 T os_arch_in_critical
00008ee8 T os_arch_init
...
...

The reason, I want to confirm this is because, I'm trying to port
some simple peripheral application to work under (rather on top
of) Mynewt OS (I think, that this might be a decent enough way
to improve my understanding on both nRF52 peripherals and
Mynewt core).

Please comment.

Thanks,
Amit


-- 
Sent from Bahamas, while drinking chi-chi and piña colada.

Re: Query on application: Bare metal or using Mynewt RTOS

Posted by amit mehta <gm...@gmail.com>.
On Fri, Mar 31, 2017 at 12:56 AM, will sanfilippo <wi...@runtime.io> wrote:
> Amit:
>
> I cannot be sure but I think I understand the problem you are having. The nordic delay routines do not use the OS and thus you are sitting in that loop constantly. The watchdog is enabled and you are probably watch dogging since the task that is supposed to tickle the watchdog is not able to run. A quick way to verify this would be to use the blinky code that uses os_time_delay().
>

Apologies for late response. Indeed, it was the problem.

Thanks,
Amit

Re: Query on application: Bare metal or using Mynewt RTOS

Posted by will sanfilippo <wi...@runtime.io>.
Amit:

I cannot be sure but I think I understand the problem you are having. The nordic delay routines do not use the OS and thus you are sitting in that loop constantly. The watchdog is enabled and you are probably watch dogging since the task that is supposed to tickle the watchdog is not able to run. A quick way to verify this would be to use the blinky code that uses os_time_delay().

I think others have commented on using the nordic SDK to do things. We did not provide a HAL for the PPI as this is a nordic specific thing (well, sort of) so you will have to do that yourself or use the SDK code.


> On Mar 30, 2017, at 3:17 PM, amit mehta <gm...@gmail.com> wrote:
> 
> On Thu, Mar 30, 2017 at 6:08 PM, marko kiiskila <ma...@runtime.io> wrote:
>> Hi Amit,
>> 
>> if you want to build without OS, take a look at apps/boot/syscfg.yml:syscfg.vals
> 
> Thank you Marko for the pointer.
> 
> On a related note, I noticed today that my simple blinky example
> that uses Nordic's peripheral library, along with the mynewt RTOS
> seem to be crashing. Logs below:
> 
> [amit@discworld mynewt-nrf52-prph]$ newt debug my_blinky
> [/home/amit/Documents/devel/ble/distrib/mynewt-nrf52-prph/repos/apache-mynewt-core/hw/bsp/nrf52dk/nrf52dk_debug.sh
> /home/amit/Documents/devel/ble/distrib/mynewt-nrf52-prph/repos/apache-mynewt-core/hw/bsp/nrf52dk
> /home/amit/Documents/devel/ble/distrib/mynewt-nrf52-prph/bin/targets/my_blinky/app/apps/blinky/blinky]
> Debugging /home/amit/Documents/devel/ble/distrib/mynewt-nrf52-prph/bin/targets/my_blinky/app/apps/blinky/blinky.elf
> GNU gdb (GNU Tools for ARM Embedded Processors) 7.8.0.20150604-cvs
> ...
> ...
> Reading symbols from
> /home/amit/Documents/devel/ble/distrib/mynewt-nrf52-prph/bin/targets/my_blinky/app/apps/blinky/blinky.elf...done.
> 0x0000856a in nrf_delay_us (number_of_us=999) at
> repos/mynewt_nordic/hw/mcu/nordic_sdk/src/ext/nRF5_SDK_11.0.0_89a8197/components/drivers_nrf/delay/nrf_delay.h:170
> 170    __ASM volatile (
> (gdb) b apps/blinky/src/main.c:57
> Breakpoint 1 at 0x8436: file apps/blinky/src/main.c, line 57.
> (gdb) c
> Continuing.
> 
> Breakpoint 1, main (argc=<optimized out>, argv=<optimized out>) at
> apps/blinky/src/main.c:59 <-- system reset probably
> 59            ++g_task1_loops;
> (gdb) list
> 54
> 55        g_led_pin = LED_BLINK_PIN;
> 56        hal_gpio_init_out(g_led_pin, 1);
> 57
> 58        while (1) {
> 59            ++g_task1_loops;
> 60
> 61            /* Wait one second.
> 62             *
> 63             * XXX: Invoke Nordic's defined method instead.
> (gdb) c
> Continuing.
> 
> Breakpoint 1, main (argc=<optimized out>, argv=<optimized out>) at
> apps/blinky/src/main.c:59 <-- once again a reset seem to have occurred
> 59            ++g_task1_loops;
> 
> 
> With this simple blinky app, I was trying to see If I can use the
> Nordic's peripheral library along with Mynewt core/Mynewt RTOS.
> I mentioned [1], this somedays back in the dev-mailing list.
> 
> Questions:
> 1: How can I debug this further ? I've used gdb, but not much in past.
> 2: Is such a approach (using Nordic's peripheral library) with mynewt
> core is indeed okay ? For example, I was interested in trying out
> Nordic's PPI examples, but couldn't find PPI related APIs under,
> Mynewt's core repo and hence, thought of using this approach.
> 
> Lastly, If someone wants to try this setup, then please follow this [2]
> readme; the code is hosted on github.
> 
> [1] http://mail-archives.apache.org/mod_mbox/incubator-mynewt-dev/201703.mbox/raw/%3cCAOUxTKOmit07kodpSt-=iozu5Xm_h44xYvwSMakrTnAZZ2px_Q@mail.gmail.com%3e/
> [2] https://github.com/bartledan/mynewt-nrf52-prph/blob/master/README.md
> 
> Thanks,
> Amit
> 
> -- 
> Sent from Bahamas, while drinking chi-chi and piña colada.


Re: Query on application: Bare metal or using Mynewt RTOS

Posted by amit mehta <gm...@gmail.com>.
On Thu, Mar 30, 2017 at 6:08 PM, marko kiiskila <ma...@runtime.io> wrote:
> Hi Amit,
>
> if you want to build without OS, take a look at apps/boot/syscfg.yml:syscfg.vals

Thank you Marko for the pointer.

On a related note, I noticed today that my simple blinky example
that uses Nordic's peripheral library, along with the mynewt RTOS
seem to be crashing. Logs below:

[amit@discworld mynewt-nrf52-prph]$ newt debug my_blinky
[/home/amit/Documents/devel/ble/distrib/mynewt-nrf52-prph/repos/apache-mynewt-core/hw/bsp/nrf52dk/nrf52dk_debug.sh
/home/amit/Documents/devel/ble/distrib/mynewt-nrf52-prph/repos/apache-mynewt-core/hw/bsp/nrf52dk
/home/amit/Documents/devel/ble/distrib/mynewt-nrf52-prph/bin/targets/my_blinky/app/apps/blinky/blinky]
Debugging /home/amit/Documents/devel/ble/distrib/mynewt-nrf52-prph/bin/targets/my_blinky/app/apps/blinky/blinky.elf
GNU gdb (GNU Tools for ARM Embedded Processors) 7.8.0.20150604-cvs
...
...
Reading symbols from
/home/amit/Documents/devel/ble/distrib/mynewt-nrf52-prph/bin/targets/my_blinky/app/apps/blinky/blinky.elf...done.
0x0000856a in nrf_delay_us (number_of_us=999) at
repos/mynewt_nordic/hw/mcu/nordic_sdk/src/ext/nRF5_SDK_11.0.0_89a8197/components/drivers_nrf/delay/nrf_delay.h:170
170    __ASM volatile (
(gdb) b apps/blinky/src/main.c:57
Breakpoint 1 at 0x8436: file apps/blinky/src/main.c, line 57.
(gdb) c
Continuing.

Breakpoint 1, main (argc=<optimized out>, argv=<optimized out>) at
apps/blinky/src/main.c:59 <-- system reset probably
59            ++g_task1_loops;
(gdb) list
54
55        g_led_pin = LED_BLINK_PIN;
56        hal_gpio_init_out(g_led_pin, 1);
57
58        while (1) {
59            ++g_task1_loops;
60
61            /* Wait one second.
62             *
63             * XXX: Invoke Nordic's defined method instead.
(gdb) c
Continuing.

Breakpoint 1, main (argc=<optimized out>, argv=<optimized out>) at
apps/blinky/src/main.c:59 <-- once again a reset seem to have occurred
59            ++g_task1_loops;


With this simple blinky app, I was trying to see If I can use the
Nordic's peripheral library along with Mynewt core/Mynewt RTOS.
I mentioned [1], this somedays back in the dev-mailing list.

Questions:
1: How can I debug this further ? I've used gdb, but not much in past.
2: Is such a approach (using Nordic's peripheral library) with mynewt
core is indeed okay ? For example, I was interested in trying out
Nordic's PPI examples, but couldn't find PPI related APIs under,
Mynewt's core repo and hence, thought of using this approach.

Lastly, If someone wants to try this setup, then please follow this [2]
readme; the code is hosted on github.

[1] http://mail-archives.apache.org/mod_mbox/incubator-mynewt-dev/201703.mbox/raw/%3cCAOUxTKOmit07kodpSt-=iozu5Xm_h44xYvwSMakrTnAZZ2px_Q@mail.gmail.com%3e/
[2] https://github.com/bartledan/mynewt-nrf52-prph/blob/master/README.md

Thanks,
Amit

-- 
Sent from Bahamas, while drinking chi-chi and piña colada.

Re: Query on application: Bare metal or using Mynewt RTOS

Posted by marko kiiskila <ma...@runtime.io>.
Hi Amit,

if you want to build without OS, take a look at apps/boot/syscfg.yml:syscfg.vals

> On Mar 30, 2017, at 12:28 AM, amit mehta <gm...@gmail.com> wrote:
> 
> On Thu, Mar 30, 2017 at 1:15 AM, will sanfilippo <wi...@runtime.io> wrote:
>> Yes, blinky uses the OS and there is a task that is running so it is not a bare metal application. The OS creates a main task and that is where things run by default. This is the short answer btw; we can go into more dertails if you like.
> 
> Thank you Will. For now it's sufficient. I'll do some more homework
> and will buzz you, in case I need more details.
> 
> Thanks,
> Amit
> 
> -- 
> Sent from Bahamas, while drinking chi-chi and piña colada.


Re: Query on application: Bare metal or using Mynewt RTOS

Posted by amit mehta <gm...@gmail.com>.
On Thu, Mar 30, 2017 at 1:15 AM, will sanfilippo <wi...@runtime.io> wrote:
> Yes, blinky uses the OS and there is a task that is running so it is not a bare metal application. The OS creates a main task and that is where things run by default. This is the short answer btw; we can go into more dertails if you like.

Thank you Will. For now it's sufficient. I'll do some more homework
and will buzz you, in case I need more details.

Thanks,
Amit

-- 
Sent from Bahamas, while drinking chi-chi and piña colada.

Re: Query on application: Bare metal or using Mynewt RTOS

Posted by will sanfilippo <wi...@runtime.io>.
Yes, blinky uses the OS and there is a task that is running so it is not a bare metal application. The OS creates a main task and that is where things run by default. This is the short answer btw; we can go into more dertails if you like.


> On Mar 29, 2017, at 2:31 PM, amit mehta <gm...@gmail.com> wrote:
> 
> Based on the following (see below), my understanding is that any
> simple application such as a blinky, which does not explicitly create
> tasks (e.g. by calling os_task_init), is still runs as an application and
> is taken care by the Mynewt RTOS, i.e. It's not a bare metal application
> Reasons are:
> 
> 1: syscfg.yml:
> The application configuration, reported by newt seem to suggest
> that there the image that would be build will have an OS. Logs below:
> 
> <snip from target list>
> $ newt target show
> targets/my_blinky
>    app=apps/blinky
>    bsp=@apache-mynewt-core/hw/bsp/nrf52dk
>    build_profile=optimized
> <snip from target list>
> 
> <snip from blinky(my_blinky) configuration>
> $ newt target config show my_blinky
>  * Setting: OS_SCHEDULING
>    * Description: Whether OS will be started or not
>    * Value: 1 <--
> ...
> ...
> * PACKAGE: sys/sysinit
>  * Setting: SYSINIT_CONSTRAIN_INIT
>    * Description: Only allow packages to be initialized by sysinit.
>    * Value: 1 <---
> 
> <snip from blinky(my_blinky) configuration>
> 
> There is no syscfg.yml file under the package (apps/blinky directory)
> to override (If It would have been overriden, it would show up in the
> above log as well)
> 
> 2: The symbols in the ELF file generated by the build system also
> has OS related code symbols. logs below:
> 
> <snip from nm>
> $ pwd
> ~/bin/targets/my_blinky/app/apps/blinky
> 
> $ arm-none-eabi-nm blinky.elf | grep -i os_
> 200022d8 B g_hal_os_tick
> 20002300 B g_os_cputime
> 20001184 b g_os_dev_list
> 200020dc B g_os_idle_ctr
> 200021fc B g_os_last_ctx_sw_time
> 20000100 D g_os_mempool_list
> 200000e8 D g_os_run_list
> 20001f78 B g_os_sanity_check_list
> 200021ec B g_os_sanity_check_mu
> 200000f0 D g_os_sleep_list
> 200021e0 B g_os_started
> 20002200 B g_os_task_list
> 2000220c B g_os_time
> 00009b4e t nrf52_os_tick_counter.part.0
> 00009b8c t nrf52_os_tick_set_ocmp
> 00008e7c T os_arch_ctx_sw
> 00008ea2 T os_arch_in_critical
> 00008ee8 T os_arch_init
> ...
> ...
> 
> The reason, I want to confirm this is because, I'm trying to port
> some simple peripheral application to work under (rather on top
> of) Mynewt OS (I think, that this might be a decent enough way
> to improve my understanding on both nRF52 peripherals and
> Mynewt core).
> 
> Please comment.
> 
> Thanks,
> Amit
> 
> 
> -- 
> Sent from Bahamas, while drinking chi-chi and piña colada.