Available firmware space on Bluz


#1

Hey Eric,

im having space issues with my code… it seems to jump very rapidly from 18% to being too large… over by 4k in size just by using serial or strings

whats the limit for text size? 110592 looks like the limit on the particle core? or is the bluz the same?

any pro tips to make it fit?

cheers,

Chris


#2

Are you including external libraries? Which ones?

The space is limited at the moment, there is only 20k available for the user app (which I believe was about the same for the Core, though that may have changed). This will grow soon, the Cloud IDE currently compiles with 4.8.4, but when we switch to 4.9.3 the system firmware shrinks and we can add more to the user app side.

Some libraries may or may not fit at the moment. Maybe we can look at what you are using and try to optimize.


#3

im using the sparkfun IMU lib (on webIDE) modified slightly for bluz, and this one with significant corrections.

i have them both working correctly individually, but putting them together gives space issues. i removed all serial1 calls and that freed up some space and i can make the libraries fit but i cant publish as the string lib would get included and push it back over the limit.

i will sit down tonight and strip down the IMU lib to just the functions i need as it currently includes absolutely everything!

the MS5837 lib i have already chopped back when i was fixing the calculations… not sure how much more i can cut out… ill have to have another look i guess.


#4

If you want to compile locally, you can use 4.9.3 and you could open up more space for the user app. This would require modifying some of the underlying firmware, but it is pretty minimal actually as it is just changing some of the values in the modules/ directory.

Wouldn’t work with the Web IDE until we get the Particle build farm switched over to 4.9.3, but it would give you a lot more space in the meantime (probably 20k-25k)

Let me know, I can pull together a list of files that would need to change.


#5

I can compile local so a list of changes will be great


#6

Sorry for the delay, here is a list of changes that need to be made. This should give you about 28K more space for the user app.

If you want to get the module info reported properly to the cloud, you would also have to change all the information here: https://github.com/bluzDK/bluzDK-firmware/blob/develop/hal/src/bluz/ota_flash_hal.c#L24. However, if you aren’t using the cloud to flash (which you can’t anyway once you make these changes) then this isn’t super critical.

I think this is everything that would need to change. It is possible I am missing one item, but I think I got it all. If something doesn’t seem to work right away, let me know and it may be there is one more change somewhere.


Particle 0.5.0 Merged
#7

so i will have to build system and user parts, what about bootloader?


#8

You little ripper

looks like its working!


#9

I’m looking at whether an arduino-style 2-board set in one of our existing prototypes could be replaced by a Bluz DK. The issue is likely to be space for our app-specific libraries. Can I use the Web IDE to get a measure of whether we are anywhere close?

So far I have only built small sketches for Bluz and have not seen any indication of space used. (In the arduino IDE this builds in 29K including the Nordic libraries and ours.)

(If I need to do a local build to establish this please point me to the doc for this.)


#10

So if you went over it would tell you by how much. These changes give an extra 6k so that should give you an idea


#11

Any idea when the build farm will be updated to 4.9.3? I am running into space issues as well and I am wondering if I should get local compiling working myself, or just wait for the update. Thanks!


Particle 0.5.0 Merged
#12

Let me check with the Particle team, last I heard this was still a bit experimental.

We would also need to release a new version of firmware to take advantage of it as well, so it wouldn’t be immediate even if Particle had support for it now. If you do need it soon, I would recommend local compile.


#13

After some unit tests I have started to put the whole of my app together and I seem to be about 5K over the flash limit. Any news on the above-mentioned upgrade?

If not I guess I should try a local build. What’s the best link for instructions on that (I am on OS/X with standard tools installed)?

BTW. Are there any plans to create a Bluz with more flash (presumably based on nRF52x)?


#14

I am waiting to hear back from Particle about getting this moved up to the Web IDE, I think there may be a few folks there on vacation this holiday week.

To do this locally, you need to change 6 files as follows:

modules/bluz/modular.mk
-USER_FIRMWARE_IMAGE_SIZE=0x5000
-USER_FIRMWARE_IMAGE_LOCATION=0x00037000
+USER_FIRMWARE_IMAGE_SIZE=0xB000
+USER_FIRMWARE_IMAGE_LOCATION=0x00031000

modules/bluz/system-part1/linker.ld

  • APP_FLASH (rx) : ORIGIN = 0x00018000, LENGTH = 0x1f000
  • APP_FLASH (rx) : ORIGIN = 0x00018000, LENGTH = 0x19000

modules/bluz/user-part/linker.ld

  • APP_FLASH (rx) : ORIGIN = 0x00037000, LENGTH = 0x05000
  • APP_FLASH (rx) : ORIGIN = 0x00031000, LENGTH = 0x0B000

modules/bluz/user-part/module_user_export.ld
-user_module_info = 0x00037000 ;
+user_module_info = 0x00031000 ;

platform/MCU/NRF51/SPARK_Firmware_Driver/inc/hw_layout.h
-#define USER_FIRMWARE_IMAGE_LOCATION 0x00037000
+#define USER_FIRMWARE_IMAGE_LOCATION 0x00031000

hal/src/nrf51/ota_flash_hal.c
-const module_bounds_t module_system_part1 = { 0x1F000, 0x18000, 0x37000, MODULE_FUNCTION_SYSTEM_PART, 1, MODULE_STORE_MAIN };
-const module_bounds_t module_user = { 0x5000, 0x37000, 0x3C000, MODULE_FUNCTION_USER_PART, 2, MODULE_STORE_MAIN};
+const module_bounds_t module_system_part1 = { 0x19000, 0x18000, 0x30000, MODULE_FUNCTION_SYSTEM_PART, 1, MODULE_STORE_MAIN };
+const module_bounds_t module_user = { 0xB000, 0x31000, 0x3C000, MODULE_FUNCTION_USER_PART, 2, MODULE_STORE_MAIN};

You do need to be a bit careful, changing other values or the wrong ones could lead to bad situations. To build on a mac, you need to install GCC ARM 4.9.3: https://launchpad.net/gcc-arm-embedded/+milestone/4.9-2015-q3-update

I just download the files and then add the location to my PATH like this:
PATH=$PATH:/usr/local/gcc-arm-none-eabi-4_9-2015q2/bin/

That way you can change version easily later. Then point that terminal to the modules/ folder inside the repository and do:
make PARTICLE_DEVELOP=1 PLATFORM=bluz APP=custom_data_service

Just change the APP name to whatever folder your code is in under the user/applications/ folder

We are certainly looking at a next-gen bluz, but are focused on getting new features pushed out for the current form at the moment.


Direct Bluetooth connection from App(No Particle Cloud)
#15

Thx for the detailed answer.

This looks like something better done by someone familiar with the source tree.

Any predictions as to when this will be available for general use via the Particle CLI?


#16

Still working through this. It requires some coordination with the Particle team as we need to change the build process, so I should know more soon.

Sorry to be a little vague, but I will come back with more details once I have them.


#17

Thx @eric.
No apologies needed - your efforts hugely appreciated :slight_smile:


#18

Wait a moment. I’m wondering if something else is wrong?

Just created an app (called TEST_TEMP_SPI) to test a BMP280 temp/ pressure sensor.

Using the appropriate contributed library called from an adapted version of Adafruit’s basic test code and compiling using the web IDE. Device is b1e243bbb4d… firmware version 1.1.47.

region `APP_FLASH' overflowed by 2192

This example is so simple that I am questioning whether I really have run out of space or is something else wrong.

Thx for clarifying.


#19

It’s likely that there is nothing wrong.

The Adafruit libraries I have seen for temp sensors usually use float’s, this is usually the source of the issue. The ARM Cortex M0 on the nrf51 doesn’t support floating point arithmetic, so we use libraries to fake it. These libraries, part of the gcc toolchain, are big and that is what usually eats up most of the flash. They won’t get included

Once we get this sorted out with the build farm, we can basically double the size and this shouldn’t be an issue.


#20

thx @eric. I can confirm that removing the use of floats avoids the problem, providing at least a temporary work-around.