peripheral_dis compilation reports RAM overflow for BBC microbit

[aguaviva]

So did peripheral_gatt_write and peripheral_hids, and I suspect the same goes for every singe sample.

Here are the steps to reproduce.

~/repos/zephyrproject/zephyr$ west build -b bbc_microbit samples/bluetooth/peripheral_dis 
[1/11] Linking C executable zephyr/zephyr_pre0.elf
FAILED: zephyr/zephyr_pre0.elf zephyr/zephyr_pre0.map /home/user0/repos/zephyrproject/zephyr/build/zephyr/zephyr_pre0.map 
: && /opt/zephyr-sdk-0.15.2/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc  -gdwarf-4 zephyr/CMakeFiles/zephyr_pre0.dir/misc/empty_file.c.obj -o zephyr/zephyr_pre0.elf  zephyr/CMakeFiles/offsets.dir/./arch/arm/core/offsets/offsets.c.obj  -fuse-ld=bfd  -Wl,-T  zephyr/linker_zephyr_pre0.cmd  -Wl,-Map=/home/user0/repos/zephyrproject/zephyr/build/zephyr/zephyr_pre0.map  -Wl,--whole-archive  app/libapp.a  zephyr/libzephyr.a  zephyr/arch/common/libarch__common.a  zephyr/arch/arch/arm/core/aarch32/libarch__arm__core__aarch32.a  zephyr/arch/arch/arm/core/aarch32/cortex_m/libarch__arm__core__aarch32__cortex_m.a  zephyr/lib/libc/minimal/liblib__libc__minimal.a  zephyr/soc/arm/nordic_nrf/nrf51/libsoc__arm__nordic_nrf__nrf51.a  zephyr/subsys/bluetooth/common/libsubsys__bluetooth__common.a  zephyr/subsys/bluetooth/host/libsubsys__bluetooth__host.a  zephyr/subsys/bluetooth/controller/libsubsys__bluetooth__controller.a  zephyr/subsys/net/libsubsys__net.a  zephyr/subsys/random/libsubsys__random.a  zephyr/drivers/clock_control/libdrivers__clock_control.a  zephyr/drivers/console/libdrivers__console.a  zephyr/drivers/gpio/libdrivers__gpio.a  zephyr/drivers/i2c/libdrivers__i2c.a  zephyr/drivers/sensor/fxos8700/libdrivers__sensor__fxos8700.a  zephyr/drivers/sensor/nrf5/libdrivers__sensor__nrf5.a  zephyr/drivers/serial/libdrivers__serial.a  zephyr/drivers/entropy/libdrivers__entropy.a  zephyr/drivers/timer/libdrivers__timer.a  zephyr/drivers/pinctrl/libdrivers__pinctrl.a  modules/hal_nordic/nrfx/libmodules__hal_nordic__nrfx.a  -Wl,--no-whole-archive  zephyr/kernel/libkernel.a  -L"/opt/zephyr-sdk-0.15.2/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.1.0/thumb/v6-m/nofp"  -L/home/user0/repos/zephyrproject/zephyr/build/zephyr  -lgcc  zephyr/arch/common/libisr_tables.a  -no-pie  -mcpu=cortex-m0  -mthumb  -mabi=aapcs  -mfp16-format=ieee  -Wl,--gc-sections  -Wl,--build-id=none  -Wl,--sort-common=descending  -Wl,--sort-section=alignment  -Wl,-u,_OffsetAbsSyms  -Wl,-u,_ConfigAbsSyms  -nostdlib  -static  -Wl,-X  -Wl,-N  -Wl,--orphan-handling=warn  -lstdc++ && cd /home/user0/repos/zephyrproject/zephyr/build/zephyr && /usr/bin/cmake -E echo
/opt/zephyr-sdk-0.15.2/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.1.0/../../../../arm-zephyr-eabi/bin/ld.bfd: zephyr/zephyr_pre0.elf section `noinit' will not fit in region `RAM'
/opt/zephyr-sdk-0.15.2/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.1.0/../../../../arm-zephyr-eabi/bin/ld.bfd: region `RAM' overflowed by 2740 bytes

ibeacon compiled and ran fine but pheripheral_dis and

[jori-nordic]

@aguaviva The bbc:microbit v1 is a resource-constrained platform, you can (unfortunately) expect the stack/kernel to bloat and run out of memory over time on platforms not marked as explicitly supported (in sample.yml).

We will welcome a patch to reduce the memory consumption of course when that happens, if you have the time.

[aguaviva]

This is a bug.

The bbc:microbit v1 should be able to run that and much more, and not being able to do this on Zephyr is a testament to how inefficient Nordic port and support is.

I bet you are trying to sell the new chips and that is why you are OK with bloating code that overflows on old ones. Look, I am not going to fix the bug for you, I am going to delete this repo and use Arduino and I won't buy Nordic chips ever again. I hope everyone sees the sort of support we can expect from Nordic and stay away from their chips.

Also, this is a bug, good try at flagging it as a feature and asking me to fix it for you.

On Mon, Jan 16, 2023 at 2:50 PM Jonathan Rico @.***> wrote:

@aguaviva https://github.com/aguaviva The bbc:microbit v1 is a resource-constrained platform, you can (unfortunately) expect the stack/kernel to bloat and run out of memory over time on platforms not marked as explicitly supported (in sample.yml).

We will welcome a patch to reduce the memory consumption of course when that happens, if you have the time.

— Reply to this email directly, view it on GitHub https://github.com/zephyrproject-rtos/zephyr/issues/53805#issuecomment-1384089431, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHVYE7OWUL6BLH44HQ3ZTTWSVGYZANCNFSM6AAAAAAT34HBRE . You are receiving this because you were mentioned.Message ID: @.***>

[jori-nordic]

not being able to do this on Zephyr is a testament to how inefficient Nordic port and support is.

I'm not arguing about the inefficiency, I do agree Zephyr can be bloated, but it also ships a lot of features. Tweaking the configuration west build -t menuconfig (or editing build/zephyr/.config) can usually free enough memory to make it fit constrained platforms.

The zephyr issue tracker is not the right place to discuss this, you can open a devzone ticket if you want an official answer. But I suspect that they will answer the same as I did, nRF Connect SDK doesn't support the bbc micro:bit v1, and any nRF51 chips for the matter.

Support in the Zephyr project for that SoC family is provided mostly by volunteers, that's why I was proposing you make a pull request and that's why I flagged it as a feature request.

PS: Here's a prj.conf snippet that makes it build again:

CONFIG_BT_GATT_CACHING=n
CONFIG_BT_LONG_WQ=n
CONFIG_BT_RX_STACK_SIZE=1000

You can build for one of the supported platforms, and then use https://github.com/HBehrens/puncover to investigate what is using up all the memory. In our case, it was mostly the stack sizes that were big (see the picture). Note that this tool is not limited to zephyr, you can can also use it to optimize your Arduino builds in the future.

Then if you have that board, you can run it, and use the stack analyzer to figure out how much of that stack memory you can safely cut. If you don't, you can try reducing it until it builds, and then run it and see what happens.

The stack sizes are usually this large to account for the callback-driven architecture in the Bluetooth host. We are trying to optimize it, but we first have to add tests to make sure we don't break anything when refactoring.

PPS: Here's my opinion on Zephyr:

Choose the right tool for the job: I personally use Arduino when prototyping, since it has an easier API and build/configuration system. There are also a lot of libraries available and a big community (so lots of tutorials, resources, etc).

For making a product using nordic chips, I would personally use either the nRF5 SDK (if building on a nRF51 chip) or the nRF Connect SDK (which uses Zephyr). I have more confidence in the robustness of that SDK, since it is stress-tested on hardware and officially supported by Nordic for production.

One of the nice things that Zephyr provides IMO is the standard driver interfaces: once you have an application, you can swap out e.g. an accelerometer from Bosch with one from ST with a single line of configuration. That can come in handy if your company e.g., has to change chip vendors because of supply issues.

[aguaviva]

Then I suggest that you remove the nrf51 based chip boards from the supported list or clarify in which situations it might work.

[jori-nordic]

Then I suggest that you remove the nrf51 based chip boards from the supported list or clarify in which situations it might work.

Yes that is a fair point. The "Supported Boards" wording of the documentation section doesn't help. In any case I won't close this issue until we have either fixed the build or clarified what boards Bluetooth supports.

[carlescufi]

Hi @aguaviva

This is a bug. The bbc:microbit v1 should be able to run that and much more, and not being able to do this on Zephyr is a testament to how inefficient Nordic port and support is.

Before making this statement, did you even try to make it compile? Did you look at the Kconfig options, did you play around with them? Did you try to understand how Zephyr defaults to a certain set of features which might not be adequate for older ICs but they can be changed to fit those if needed? Did you read through old issues where we discussed this?

This is not a bug. Zephyr is an open source project. I suggest you educate yourself with how open source works before making statements like those. Open Source projects are "best effort", which means that there are no guarantees about them, nor timelines. You try to use it for your purpose and, if it doesn't work, you politely request improvements or make those yourself. That is how open source works and that is how Zephyr works.

I bet you are trying to sell the new chips and that is why you are OK with bloating code that overflows on old ones.

Well you bet wrongly. Should I remind you that Nordic's official SoftDevice has not supported nRF51 for a while, but the open source controller continues to support it? Now why would Nordic ensure that nRF51 works in Zephyr (barring memory issues, but that's another story), which takes time and effort on our side if what you suggest were true?

Look, I am not going to fix the bug for you, I am going to delete this repo and use Arduino and I won't buy Nordic chips ever again. I hope everyone sees the sort of support we can expect from Nordic and stay away from their chips. Also, this is a bug, good try at flagging it as a feature and asking me to fix it for you.

I believe your statements and language violate our code of conduct. I will report this to the project leadership.

[aguaviva]

Before making this statement, did you even try to make it compile?

Yes, I did compile it, you should check the first post. As for playing with the Kconfig settings I expect Nordic to have done that, and since the chip is in the list of the supported boards the peripheral_dis should work out of the box.

This is not a bug.

It is a bug because the sample doesn't work, it takes all the memory just to run the discovery services.

Zephyr is an open source project.

Zephyr is open source, but Nordic is a corporation. Making sure Nordic chips work well in Zephyr is a paid job, that is why you are here. So in the name of open source please don't ask Nordic's customers to do your job and for free.

I believe your statements and language violate our code of conduct.

Not sure about that, but I am sure Nordic won't appreciate to hear their customers are asked to 'fix the platform's issue yourself and send us a PRs (for free)'

[carlescufi]

This is not a bug.

It is a bug because the sample doesn't work, it takes all the memory just to run the discovery services.

The definition of bug is different for every project, I am not aware of a universal definition applicable to all projects. In the case of Zephyr, the fact that a particular sample doesn't fit in a particular board in its default configuration, to my knowledge, is not considered a bug.

Zephyr is an open source project.

Zephyr is open source, but Nordic is a corporation. Making sure Nordic chips work well in Zephyr is a paid job, that is why you are here. So in the name of open source please don't ask Nordic's customers to do your job and for free.

And that's why Nordic offers the nRF Connect SDK, an SDK based on Zephyr but that comes with full commercial support.

I believe your statements and language violate our code of conduct.

Not sure about that, but I am sure Nordic won't appreciate to hear their customers are asked to 'fix the platform's issue yourself and send us a PRs (for free)'

We are definitely not doing that. For the nRF51 series, you have the officially supported software solution, which can be used freely to develop nRF51-based applications with the full support from Nordic. If, however, you choose to try and use Zephyr with the nRF51, then you are not using the officially supported software framework, and thus the level of support differs substantially.

[aguaviva]

The definition of bug is different for every project, I am not aware of a universal definition applicable to all projects.

Good try, and good luck with that. Bye.

[jori-nordic]

Alright then, I propose to close the issue so the conversation doesn't degrade a bit more.

@carlescufi you mentioned some work was being started to clarify what is supported and what is actually built/tested in regression. Could you close with a link to that if you have one?

[stephanosio]

Not a bug.