Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SRAM not sufficient when building BT Mesh developer guide build on BBC Micro-bit #21833

Closed
ggk4u opened this issue Jan 10, 2020 · 18 comments
Closed

Comments

@ggk4u
Copy link

ggk4u commented Jan 10, 2020

When trying to compile sample Mesh code downloaded from BT website(BT Mesh developer guide), I am getting following compilation error...

zephyr version I am using is "Zephyr version: 2.0.99"

Memory region Used Size Region Size %age Used
FLASH: 96550 B 256 KB 36.83%
SRAM: 17528 B 16 KB 106.98%
IDT_LIST: 152 B 2 KB 7.42/home/user/zephyr-sdk-0.10.3/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/8.3.0/../../../../arm-zephyr-eabi/bin/ld: zephyr/zephyr_prebuilt.elf section datas' will not fit in region SRAM'

@aescolar
Copy link
Member

CC @jhedberg

@jhedberg
Copy link
Member

I think you'll need to look at the app's build configuration (prj.conf probably) to see what you can fine-tune. Perhaps some thread stack size can be reduced, buffer sizes shrunk or number of buffers reduced. Yet another option is to use the same Zephyr version that the developer guide was originally created for, which I believe is 1.14.

@bluetooth-mdw do you think you'd be able to help out here?

@ghost
Copy link

ghost commented Jan 13, 2020

Hi, the current release of the SIG's Bluetooth Mesh Developer Study Guide is based on V1.12 of the Zephyr SDK. If you take a look at page 6 of the Coding Exercises Introduction document, you'll see that it says this.

Try checking out V1.12 and you should be OK.

FYI I have created version 2.0 of this educational resource and it is based on v1.14 of Zephyr which contains a Bluetooth qualified implementation of Zephyr. This release is currently in review and so will hopefully be released quite soon. Micro:bit is no longer used however, due to its very limited amount of memory. I'll announce the availability of the new version via my Twitter account (@bluetooth-mdw).

Hope this helps.

@ggk4u
Copy link
Author

ggk4u commented Jan 24, 2020

@bluetooth-mdw

Thanks for the help.
Meanwhile I could able to build it successfully after disabling debug config switches.

@ghost
Copy link

ghost commented Jan 24, 2020

OK, that's good to hear :-)

@ggk4u
Copy link
Author

ggk4u commented Jan 24, 2020

@bluetooth-mdw

But when I place the biinary of Light along with the compiled code of Switch it is working fine but when I compile Light and flash then the switch+Light combo is not working...

I mean
Switch(compiled solution and flashed ) + Light(Binary) - This is working
Switch(compiled solution and flashed ) + Light(compiled solution and flashed ) - This is not working

Did I miss anything over here?

@ghost
Copy link

ghost commented Jan 24, 2020

You'll need those debug options enabled to find out what the problem is. Could be SEQ value reuse, for example. Change the source address of your switch node to check for this. But really, you need to see what the stack is doing and I'm afraid the only way to do that is to switch on appropriate debug options.

@ghost
Copy link

ghost commented Jan 24, 2020

p.s. you can replace the micro:bit DAPLink firmware with JLink using the instructions at https://www.segger.com/products/debug-probes/j-link/models/other-j-links/bbc-microbit-j-link-upgrade/. You can then use Nordic command line tool nrfjprog -e to completely erase the device and start again. You'll need to reinstall the microbit firmware (see https://microbit.org/guide/firmware/) to have it mount as a USB mass storage device again.

@ggk4u
Copy link
Author

ggk4u commented Feb 5, 2020

@bluetooth-mdw
I am trying to see how to enable debug options but the monet I enable them the SRAM size is crossing 16KB and compilation is failing...
I am unable to figure out how to reduce SRAM for the package provided.

Meanwhile I tried to upgrade the firmware as mentioned above but this doesnt help as the compiled code is crossing 16KB of SRAM.

Can I move any of the code to some other memory to fit SRAM?

@ghost
Copy link

ghost commented Feb 5, 2020

Hi, I just tested and had no SRAM problems. Are you sure you are using the 1.12 version of the Zephyr SDK? And the solution projects as packaged include the following debug options already:

CONFIG_BT_DEBUG_LOG=y
CONFIG_BT_MESH_DEBUG_ACCESS=y
CONFIG_BT_MESH_DEBUG=y

Here's what I did. First I had to regress my Zephyr source to 1.12. So from within my zephyr source directory, I ran:

git checkout tags/v1.12.0

There have been some environment variable changes since 1.12 so you have to make a couple of manual environment variable changes so that your environment is in line with the requirements of this version of Zephyr:

C:\tmp\MeshDeveloperStudyGuide\code\solution\Switch>set ZEPHYR_TOOLCHAIN_VARIANT=gccarmemb
C:\tmp\MeshDeveloperStudyGuide\code\solution\Switch>set GCCARMEMB_TOOLCHAIN_PATH=C:\gnu_arm_embedded

Then, to build and install:

C:\tmp\MeshDeveloperStudyGuide\code\solution\Switch>mkdir build

C:\tmp\MeshDeveloperStudyGuide\code\solution\Switch>cd build

C:\tmp\MeshDeveloperStudyGuide\code\solution\Switch\build>cmake -GNinja -DBOARD=bbc_microbit ..
CMake Deprecation Warning at C:/workspaces/zephyr_source/zephyr/cmake/app/boilerplate.cmake:38 (cmake_policy):
  The OLD behavior for policy CMP0000 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.
Call Stack (most recent call first):
  CMakeLists.txt:4 (include)


-- Found PythonInterp: C:/Python37/python.exe (found suitable version "3.7.3", minimum required is "3.4")
-- Selected BOARD bbc_microbit
Zephyr version: 1.12.0
C:/tmp/MeshDeveloperStudyGuide/code/solution/Switch/prj_bbc_microbit.conf:11: warning: BT (defined at subsys/bluetooth/Kconfig:10) set more than once. Old value: "y", new value: "y".
Parsing Kconfig tree in C:/workspaces/zephyr_source/zephyr//Kconfig
Using C:/workspaces/zephyr_source/zephyr/boards/arm/bbc_microbit/bbc_microbit_defconfig as base
Merging C:/tmp/MeshDeveloperStudyGuide/code/solution/Switch/prj_bbc_microbit.conf
-- Generating zephyr/include/generated/generated_dts_board.h
C:/workspaces/zephyr_source/zephyr//scripts/dts/extract_dts_includes.py:572: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working
  and isinstance(merge_dct[k], collections.Mapping)):
-- Cache files will be written to: C:\Users\mwoolley\AppData\Local/.cache/zephyr
-- The C compiler identification is GNU 7.3.1
-- The CXX compiler identification is GNU 7.3.1
-- The ASM compiler identification is GNU
-- Found assembler: C:/gnu_arm_embedded/bin/arm-none-eabi-gcc.exe
-- Performing Test toolchain_is_ok
-- Performing Test toolchain_is_ok - Success
-- Configuring done
-- Generating done
-- Build files have been written to: C:/tmp/MeshDeveloperStudyGuide/code/solution/Switch/build

C:\tmp\MeshDeveloperStudyGuide\code\solution\Switch\build>ninja
[1/149] Generating always_rebuild
Building for board bbc_microbit
[144/149] Linking C executable zephyr\zephyr_prebuilt.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:      111592 B       256 KB     42.57%
            SRAM:       15380 B        16 KB     93.87%
        IDT_LIST:         132 B         2 KB      6.45%
[149/149] Linking C executable zephyr\zephyr.elf

C:\tmp\MeshDeveloperStudyGuide\code\solution\Switch\build>copy zephyr\zephyr.hex d:
        1 file(s) copied.
		

And with a micro:bit plugged into a USB port, I used Windows Device Manager to find out what port it had been assigned, connected to it using Putty and as expected, saw this:

switch
Press button A or button B
[bt] [INF] hci_vs_init: HW Platform: Nordic Semiconductor (0x0002)
[bt] [INF] hci_vs_init: HW Variant: nRF51x (0x0001)
[bt] [INF] hci_vs_init: Firmware: Standard Bluetooth controller (0x00) Version 1                                                    .12 Build 0
[bt] [INF] bt_dev_show_info: Identity: d9:64:36:0e:87:01 (random)
[bt] [INF] bt_dev_show_info: HCI: version 5.0 (0x09) revision 0x0000, manufactur                                                    er 0x05f1
[bt] [INF] bt_dev_show_info: LMP: version 5.0 (0x09) subver 0xffff
Bluetooth initialised OK
Mesh initialised OK
[bt] [INF] bt_mesh_provision: Primary Element: 0x0001
[bt] [DBG] bt_mesh_provision: (0x200012d0) net_idx 0x0000 flags 0x00 iv_index 0x                                                    0000
[bt] [DBG] bt_mesh_comp_provision: (0x200012d0) addr 0x0001 elem_count 1
[bt] [DBG] bt_mesh_comp_provision: (0x200012d0) addr 0x0001 mod_count 4 vnd_mod_                                                    count 0
Provisioning completed
self-configuring...
[bt] [DBG] model_send: (0x200012d0) net_idx 0x0000 app_idx 0xfffe dst 0x0001
[bt] [DBG] model_send: (0x200012d0) len 20: 000000000123456789abcdef0123456789ab                                                    cdef
[bt] [DBG] model_send: (0x200012d0) net_idx 0x0000 app_idx 0xfffe dst 0x0001
[bt] [DBG] model_send: (0x200012d0) len 8: 803d010000000110
bound appkey to generic onoff server model
[bt] [DBG] model_send: (0x200012d0) net_idx 0x0000 app_idx 0xfffe dst 0x0001
[bt] [DBG] model_send: (0x200012d0) len 8: 803d010000000200
self-configuration complete
provisioned, configured and ready

So if you have your 1.12 environment set up correctly, you should be able to build and install with some debug options set and then watch what happens when you send a message.

I've just chased my reviewer on the ETA for the new release of our mesh developer study guide. That release will get it onto an LTS version of Zephyr.

Hope this helps.

@ggk4u
Copy link
Author

ggk4u commented Feb 5, 2020

@bluetooth-mdw
No, I am actually using the latest zephyr(Zephyr version: 2.0.99) and trying to get it working with the latest zephyr and for some reason switch light combination is not working as expected when taken from the solution but when the light node is replaced with a pre-compiled light binary it is working fine.

@ghost
Copy link

ghost commented Feb 5, 2020

OK, well I'm afraid there's not much I can do to help you as things stand then. I haven't attempted to upgrade to Zephyr 2.0 yet so I don't know what the issues are. 1.14 is my preferred release because it has LTS status and a qualified Bluetooth stack.

@ggk4u
Copy link
Author

ggk4u commented Feb 5, 2020

Ok, I will give a try with zephyr 1.12 or 1.14, Once it works I can think about what is causing issue with zephyr 2.0 :)

Thanks for the support.

@ghost
Copy link

ghost commented Feb 5, 2020

Sounds like a good plan :-)

@ggk4u
Copy link
Author

ggk4u commented Feb 12, 2020

@bluetooth-mdw

I could able to successfully run the mesh switch using 1.12v of zephyr, But the latest looks like has some issue configuring MESH

@ghost
Copy link

ghost commented Feb 12, 2020

Configuration is performed from within code. This is explained in the documentation.

FYI V2.0 of the Bluetooth Mesh Developer Study Guide should be available for download some time this week. It does not use micro:bit anymore, however.

@carlescufi
Copy link
Member

The Mesh study guide is not part of Zephyr, but we will investigate the recent bloat of the BLE functionality to get things running on the micro;bit again.

@ghost
Copy link

ghost commented May 14, 2020

The Bluetooth SIG mesh developer study guide V2.0 has since been released and now uses Nordic Thingy devices with Zephyr 1.14. But it would be nice to make sure micro:bit continues to be an option, albeit without the ability to support proper provisioning and configuration, which afaik has never been possible with so little memory.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants