"Missing PLATFORM_SPECIFIC_HAL_LIB" when attempting to compile #1

Closed
ncoghlan opened this Issue Jan 1, 2016 · 47 comments

Comments

Projects
None yet
4 participants
@ncoghlan

ncoghlan commented Jan 1, 2016

I have one of the Microbit boards that are participating in the MicroPython world tour, and am attempting to create a reusable Docker build environment for them: https://github.com/ncoghlan/microbit/tree/master/devenv

However, after running through the environment setup instructions, even a basic yt build command is failing for me: bbcmicrobit/micropython#143

While I've never had a working environment, @dpgeorge indicated on the issue that a yt update broke his environment as well.

What I've been able to figure out so far suggests that some of the expected settings in the target.json file may have changed, but I'm not clear on what needs to be fixed.

@ncoghlan

This comment has been minimized.

Show comment
Hide comment
@ncoghlan

ncoghlan Jan 1, 2016

The specific target I'm working with is bbc-microbit-classic-gcc (as well as bbc-microbit-classic-gcc-nosd)

ncoghlan commented Jan 1, 2016

The specific target I'm working with is bbc-microbit-classic-gcc (as well as bbc-microbit-classic-gcc-nosd)

@finneyj

This comment has been minimized.

Show comment
Hide comment
@finneyj

finneyj Jan 1, 2016

Contributor

hi @ncoghlan / @dpgeorge

yes - there's a dependency bug was recently introduced in the mbed-gcc target (which the microbit) target derives from. The issue is that yotta is accidentally pulling in modules from mbed-os as well as mbed-classic. I very recently worked through this with some of the BBC/Microsoft guys, so reposting details of a workaround below. Sadly I don't have permissions to update the public yotta target - waiting on someone from ARM to help with that. Hope this helps:

--- repost ---

We tracked this back to a bug/assumption in the mbed-gcc yotta target recently. Replicating your build, it's making a bit of an assumption and pulling in the mbed-os yotta modules, which we aren't using for micro:bit due to our SRAM limitations... We're running on mbed-classic.

The bbc-microbit-classic-gcc needs a small update, but I'm afraid I don't have permissions to push this back to the registry. I'll ask @jaustin at ARM to update this. Jonny - we can also update to the latest bootloader at the same time. Please drop me an email/skype to sync up.

In the meantime, the workaround is straightforward:

Delete all the content you don't want. Easiest is to simply delete the whole microbit directory rm -r microbit

pull a fresh copy of the yotta module:

git clone https://github.com/lancaster-university/microbit
cd microbit/
yotta target bbc-microbit-classic-gcc
Use your favourite editor to edit yotta_targets/bbc-microbit-classic-gcc/target.json
Change line 12 to refer to version 0.1.3 of the mbed-gcc module. as below:
"inherits": {
"mbed-gcc": "0.1.3"
},
you should then be able to build using yotta build in the root directory.

Can you let me know if this works for you, but please leave this issue live until it's fixed in the yotta registry to others can see this workaround.

Contributor

finneyj commented Jan 1, 2016

hi @ncoghlan / @dpgeorge

yes - there's a dependency bug was recently introduced in the mbed-gcc target (which the microbit) target derives from. The issue is that yotta is accidentally pulling in modules from mbed-os as well as mbed-classic. I very recently worked through this with some of the BBC/Microsoft guys, so reposting details of a workaround below. Sadly I don't have permissions to update the public yotta target - waiting on someone from ARM to help with that. Hope this helps:

--- repost ---

We tracked this back to a bug/assumption in the mbed-gcc yotta target recently. Replicating your build, it's making a bit of an assumption and pulling in the mbed-os yotta modules, which we aren't using for micro:bit due to our SRAM limitations... We're running on mbed-classic.

The bbc-microbit-classic-gcc needs a small update, but I'm afraid I don't have permissions to push this back to the registry. I'll ask @jaustin at ARM to update this. Jonny - we can also update to the latest bootloader at the same time. Please drop me an email/skype to sync up.

In the meantime, the workaround is straightforward:

Delete all the content you don't want. Easiest is to simply delete the whole microbit directory rm -r microbit

pull a fresh copy of the yotta module:

git clone https://github.com/lancaster-university/microbit
cd microbit/
yotta target bbc-microbit-classic-gcc
Use your favourite editor to edit yotta_targets/bbc-microbit-classic-gcc/target.json
Change line 12 to refer to version 0.1.3 of the mbed-gcc module. as below:
"inherits": {
"mbed-gcc": "0.1.3"
},
you should then be able to build using yotta build in the root directory.

Can you let me know if this works for you, but please leave this issue live until it's fixed in the yotta registry to others can see this workaround.

@jamesadevine

This comment has been minimized.

Show comment
Hide comment
@jamesadevine

jamesadevine Jan 1, 2016

Contributor

@finneyj edited, and bumped the version.

You should also have rights now BTW!

It worked for me, but I never had a broken build environment - can someone verify?

Best,

James.

Contributor

jamesadevine commented Jan 1, 2016

@finneyj edited, and bumped the version.

You should also have rights now BTW!

It worked for me, but I never had a broken build environment - can someone verify?

Best,

James.

@jamesadevine

This comment has been minimized.

Show comment
Hide comment
@jamesadevine

jamesadevine Jan 1, 2016

Contributor

By verify I mean rm -r the yotta_targets folder and then do a yt build :) Happy new year!

Contributor

jamesadevine commented Jan 1, 2016

By verify I mean rm -r the yotta_targets folder and then do a yt build :) Happy new year!

@finneyj

This comment has been minimized.

Show comment
Hide comment
@finneyj

finneyj Jan 1, 2016

Contributor

cool - thanks James. Didn't know you still had permissions on this!

Contributor

finneyj commented Jan 1, 2016

cool - thanks James. Didn't know you still had permissions on this!

@ncoghlan

This comment has been minimized.

Show comment
Hide comment
@ncoghlan

ncoghlan Jan 1, 2016

Thanks folks - the update has fixed this particular problem, so using the Docker based setup linked above now results in yt build failing with

/usr/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld: source/microbit-micropython section `.text' will not fit in region `FLASH'
/usr/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld: source/microbit-micropython section `.bss' will not fit in region `RAM'
/usr/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld: region RAM overflowed with stack
/usr/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld: region `FLASH' overflowed by 45280 bytes
/usr/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld: region `RAM' overflowed by 5116 bytes

That could just be a setup problem in my environment though, so I'll double check all the earlier steps in the image build.

ncoghlan commented Jan 1, 2016

Thanks folks - the update has fixed this particular problem, so using the Docker based setup linked above now results in yt build failing with

/usr/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld: source/microbit-micropython section `.text' will not fit in region `FLASH'
/usr/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld: source/microbit-micropython section `.bss' will not fit in region `RAM'
/usr/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld: region RAM overflowed with stack
/usr/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld: region `FLASH' overflowed by 45280 bytes
/usr/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld: region `RAM' overflowed by 5116 bytes

That could just be a setup problem in my environment though, so I'll double check all the earlier steps in the image build.

@finneyj

This comment has been minimized.

Show comment
Hide comment
@finneyj

finneyj Jan 1, 2016

Contributor

thanks @ncoghlan.

Looks like you're running out of memory with that particular build... We are very constrained on this device. Maybe on of the micropython folks can help you with this one.

Contributor

finneyj commented Jan 1, 2016

thanks @ncoghlan.

Looks like you're running out of memory with that particular build... We are very constrained on this device. Maybe on of the micropython folks can help you with this one.

@dpgeorge

This comment has been minimized.

Show comment
Hide comment
@dpgeorge

dpgeorge Jan 1, 2016

We need to use bbc-microbit-classic-gcc-nosd (no soft device variant)... @jamesadevine it doesn't look like that one has been updated to use 0.1.3 of mbed-gcc? I just deleted my yotta_* directories and did yt target and yt update but it still fails with the PLATFORM_SPECIFIC_HAL_LIB error.

If I patch yotta_targets/bbc-microbit-classic-gcc-nosd/target.json as described above, then it does compile, but it doesn't link due to RAM overflow. It seems that this latest version of the target/modules takes 1244 extra bytes of RAM compared to the previous. That's not good for us. Is this possible to fix? How do I revert to a previos version of the target/modules that does actually work?

dpgeorge commented Jan 1, 2016

We need to use bbc-microbit-classic-gcc-nosd (no soft device variant)... @jamesadevine it doesn't look like that one has been updated to use 0.1.3 of mbed-gcc? I just deleted my yotta_* directories and did yt target and yt update but it still fails with the PLATFORM_SPECIFIC_HAL_LIB error.

If I patch yotta_targets/bbc-microbit-classic-gcc-nosd/target.json as described above, then it does compile, but it doesn't link due to RAM overflow. It seems that this latest version of the target/modules takes 1244 extra bytes of RAM compared to the previous. That's not good for us. Is this possible to fix? How do I revert to a previos version of the target/modules that does actually work?

@finneyj

This comment has been minimized.

Show comment
Hide comment
@finneyj

finneyj Jan 1, 2016

Contributor

hi @dpgeorge,

ouch - 1244 additional bytes of RAM is not OK for anyone... we need to find where this is coming from and shave it back off. We needed to make an urgent update to the more recent mbed BLE_API and nrf51 SDKs a little before Christmas (don't ask...) My guess is that it's likely coming from in there. :-/ Strange though, as the ARM guys said they'd reduced the RAM footprint, not increased it.

Reverting is a little tricky in this instance the mbed changes restructured the code - pulling the nrf51 SDK outside of the low level BLE libraries

The releases of microbit-dal are now tagged, so if this bug is in there you should be able to revert by specifying the version you want in the appropriate yotta file. If it's in one of the support modules it'll be a bit mire tricky.

joe

Contributor

finneyj commented Jan 1, 2016

hi @dpgeorge,

ouch - 1244 additional bytes of RAM is not OK for anyone... we need to find where this is coming from and shave it back off. We needed to make an urgent update to the more recent mbed BLE_API and nrf51 SDKs a little before Christmas (don't ask...) My guess is that it's likely coming from in there. :-/ Strange though, as the ARM guys said they'd reduced the RAM footprint, not increased it.

Reverting is a little tricky in this instance the mbed changes restructured the code - pulling the nrf51 SDK outside of the low level BLE libraries

The releases of microbit-dal are now tagged, so if this bug is in there you should be able to revert by specifying the version you want in the appropriate yotta file. If it's in one of the support modules it'll be a bit mire tricky.

joe

@finneyj

This comment has been minimized.

Show comment
Hide comment
@finneyj

finneyj Jan 1, 2016

Contributor

@dpgeorge - I'm showing a clean build of the microbit repo coming in at 3064 bytes bss, with microbit-dal using 1020 bytes, and the rest coming from the nrf51 / mbed SDKs.

From memory, this is pretty much exactly where it was previously.. can I ask what you're seeing on your build? Is it possible that there are some residual mbed-os components in your build?

Contributor

finneyj commented Jan 1, 2016

@dpgeorge - I'm showing a clean build of the microbit repo coming in at 3064 bytes bss, with microbit-dal using 1020 bytes, and the rest coming from the nrf51 / mbed SDKs.

From memory, this is pretty much exactly where it was previously.. can I ask what you're seeing on your build? Is it possible that there are some residual mbed-os components in your build?

@jamesadevine

This comment has been minimized.

Show comment
Hide comment
@jamesadevine

jamesadevine Jan 1, 2016

Contributor

@dpgeorge I've just removed both my yotta_modules and yotta_targets folders, and performed a fresh pull.

It fetched version 0.1.4, which is the updated target. Can you please verify?

Contributor

jamesadevine commented Jan 1, 2016

@dpgeorge I've just removed both my yotta_modules and yotta_targets folders, and performed a fresh pull.

It fetched version 0.1.4, which is the updated target. Can you please verify?

@dpgeorge

This comment has been minimized.

Show comment
Hide comment
@dpgeorge

dpgeorge Jan 1, 2016

@jamesadevine I'm a bit confused as to what you are building. I'm trying to build micropython, by doing:

$ git clone https://github.com/bbcmicrobit/micropython.git
$ yt target bbc-microbit-classic-gcc-nosd
$ yt update
$ yt build

It fails with "Missing PLATFORM_SPECIFIC_HAL_LIB". If I manually edit yotta_targets/bbc-microbit-classic-gcc-nosd/target.json as described above (to make it point to mbed-gcc 0.1.3) then it builds, but linking fails due to overflow in RAM.

dpgeorge commented Jan 1, 2016

@jamesadevine I'm a bit confused as to what you are building. I'm trying to build micropython, by doing:

$ git clone https://github.com/bbcmicrobit/micropython.git
$ yt target bbc-microbit-classic-gcc-nosd
$ yt update
$ yt build

It fails with "Missing PLATFORM_SPECIFIC_HAL_LIB". If I manually edit yotta_targets/bbc-microbit-classic-gcc-nosd/target.json as described above (to make it point to mbed-gcc 0.1.3) then it builds, but linking fails due to overflow in RAM.

@jamesadevine

This comment has been minimized.

Show comment
Hide comment
@jamesadevine

jamesadevine Jan 1, 2016

Contributor

Ah, did not update the nosd stream. Will let you know when I've updated it :) Sorry for the confusion.

James.

On 1 Jan 2016, at 18:06, Damien George <notifications@github.commailto:notifications@github.com> wrote:

@jamesadevinehttps://github.com/jamesadevine I'm a bit confused as to what you are building. I'm trying to build micropython, by doing:

$ git clone https://github.com/bbcmicrobit/micropython.git
$ yt target bbc-microbit-classic-gcc-nosd
$ yt update
$ yt build

It fails with "Missing PLATFORM_SPECIFIC_HAL_LIB". If I manually edit yotta_targets/bbc-microbit-classic-gcc-nosd/target.json as described above (to make it point to mbed-gcc 0.1.3) then it builds, but linking fails due to overflow in RAM.


Reply to this email directly or view it on GitHubhttps://github.com/lancaster-university/microbit-targets/issues/1#issuecomment-168323220.

Contributor

jamesadevine commented Jan 1, 2016

Ah, did not update the nosd stream. Will let you know when I've updated it :) Sorry for the confusion.

James.

On 1 Jan 2016, at 18:06, Damien George <notifications@github.commailto:notifications@github.com> wrote:

@jamesadevinehttps://github.com/jamesadevine I'm a bit confused as to what you are building. I'm trying to build micropython, by doing:

$ git clone https://github.com/bbcmicrobit/micropython.git
$ yt target bbc-microbit-classic-gcc-nosd
$ yt update
$ yt build

It fails with "Missing PLATFORM_SPECIFIC_HAL_LIB". If I manually edit yotta_targets/bbc-microbit-classic-gcc-nosd/target.json as described above (to make it point to mbed-gcc 0.1.3) then it builds, but linking fails due to overflow in RAM.


Reply to this email directly or view it on GitHubhttps://github.com/lancaster-university/microbit-targets/issues/1#issuecomment-168323220.

@jamesadevine

This comment has been minimized.

Show comment
Hide comment
@jamesadevine

jamesadevine Jan 1, 2016

Contributor

@dpgeorge The nosd branch should also now be up to date, once again sorry for the confusion :D

Contributor

jamesadevine commented Jan 1, 2016

@dpgeorge The nosd branch should also now be up to date, once again sorry for the confusion :D

@finneyj

This comment has been minimized.

Show comment
Hide comment
@finneyj

finneyj Jan 1, 2016

Contributor

@jamesadevine - confirmed. I just pulled and built the micropython repo without seeing any problems with the target.

I can repro the out of memory condition on build also. Taking a quick look at the map file out of the compiler, and can't see anything obviously wrong.

@dpgeorge - noticed that the micropythin heap seems to be set at ~10K, with is pushing the bss section higher than we normally run it. is this intentional / accounted for?

Contributor

finneyj commented Jan 1, 2016

@jamesadevine - confirmed. I just pulled and built the micropython repo without seeing any problems with the target.

I can repro the out of memory condition on build also. Taking a quick look at the map file out of the compiler, and can't see anything obviously wrong.

@dpgeorge - noticed that the micropythin heap seems to be set at ~10K, with is pushing the bss section higher than we normally run it. is this intentional / accounted for?

@dpgeorge

This comment has been minimized.

Show comment
Hide comment
@dpgeorge

dpgeorge Jan 1, 2016

Yes it now compiles for me, thanks @jamesadevine!

But the out of memory issue is still there. Yes we have about 10k for the heap (allocated in the bss) and that's the way it's been for months. What has changed that we are now getting an overflow?

dpgeorge commented Jan 1, 2016

Yes it now compiles for me, thanks @jamesadevine!

But the out of memory issue is still there. Yes we have about 10k for the heap (allocated in the bss) and that's the way it's been for months. What has changed that we are now getting an overflow?

@finneyj

This comment has been minimized.

Show comment
Hide comment
@finneyj

finneyj Jan 1, 2016

Contributor

Thanks @dpgeorge.

Unknown - nothing has changed that i'm aware of. BSS of a microbit build has always been around 3K under gcc (and about 300 bytes less under armcc). A native microbit-dal build comes in just under 3K, and micropython seems to be at 3200 bytes due to a few additional python specific modules. This is much higher than i'd like (as microbit-dal is only 1K), but it's all static data in our underlying SDKs, so we've just put up with it thus far. I'm at a loss at how you managed to have 1.2K less previously...

The only difference in the recent updates is bringing the BLE_API and nrf51822 modules up to date, and adding the nrf51 SDK (as this is now an explicit requirement for nrf51822, whereas previously it was bundled within the nrf51822 module).

I guess there weren't any micropython specific optimisations? or patches to reduce stack size / GCC heap size?

At present a micropython build looks like (approx):

0-10K: uPy HEAP
10-13K: BSS
13K - 15K: HEAP
14K - 16K: STACK

The last two are overlapped, hence the overflow issue.

Can you shed any light on how you might have lad a smaller footprint in the past?

Contributor

finneyj commented Jan 1, 2016

Thanks @dpgeorge.

Unknown - nothing has changed that i'm aware of. BSS of a microbit build has always been around 3K under gcc (and about 300 bytes less under armcc). A native microbit-dal build comes in just under 3K, and micropython seems to be at 3200 bytes due to a few additional python specific modules. This is much higher than i'd like (as microbit-dal is only 1K), but it's all static data in our underlying SDKs, so we've just put up with it thus far. I'm at a loss at how you managed to have 1.2K less previously...

The only difference in the recent updates is bringing the BLE_API and nrf51822 modules up to date, and adding the nrf51 SDK (as this is now an explicit requirement for nrf51822, whereas previously it was bundled within the nrf51822 module).

I guess there weren't any micropython specific optimisations? or patches to reduce stack size / GCC heap size?

At present a micropython build looks like (approx):

0-10K: uPy HEAP
10-13K: BSS
13K - 15K: HEAP
14K - 16K: STACK

The last two are overlapped, hence the overflow issue.

Can you shed any light on how you might have lad a smaller footprint in the past?

@dpgeorge

This comment has been minimized.

Show comment
Hide comment
@dpgeorge

dpgeorge Jan 1, 2016

Looking at the .map file, I see that there is a lot of BLE stuff included in the build. For example, nRF5xGattServer.cpp.o from ble-nrf51822 occupies 520 bytes of the bss.

dpgeorge commented Jan 1, 2016

Looking at the .map file, I see that there is a lot of BLE stuff included in the build. For example, nRF5xGattServer.cpp.o from ble-nrf51822 occupies 520 bytes of the bss.

@finneyj

This comment has been minimized.

Show comment
Hide comment
@finneyj

finneyj Jan 1, 2016

Contributor

Yes - those underlying libs are very hungry. Did you find a way to optimize these out in the past?

Contributor

finneyj commented Jan 1, 2016

Yes - those underlying libs are very hungry. Did you find a way to optimize these out in the past?

@finneyj

This comment has been minimized.

Show comment
Hide comment
@finneyj

finneyj Jan 1, 2016

Contributor

p.s. would you happen to have a map file from an older micro-python build that we can compare to?

Contributor

finneyj commented Jan 1, 2016

p.s. would you happen to have a map file from an older micro-python build that we can compare to?

@dpgeorge

This comment has been minimized.

Show comment
Hide comment
@dpgeorge

dpgeorge Jan 1, 2016

I guess there weren't any micropython specific optimisations? or patches to reduce stack size / GCC heap size?

No. We were using stock modules.

Yes - those underlying libs are very hungry. Did you find a way to optimize these out in the past?

Well, I guess they were just not included. We don't need BLE stuff, so I assumed it wasn't linked in.

p.s. would you happen to have a map file from an older micro-python build that we can compare to?

Unfortunately not... I was deleting everything trying to get it to compile with the latest changes!

dpgeorge commented Jan 1, 2016

I guess there weren't any micropython specific optimisations? or patches to reduce stack size / GCC heap size?

No. We were using stock modules.

Yes - those underlying libs are very hungry. Did you find a way to optimize these out in the past?

Well, I guess they were just not included. We don't need BLE stuff, so I assumed it wasn't linked in.

p.s. would you happen to have a map file from an older micro-python build that we can compare to?

Unfortunately not... I was deleting everything trying to get it to compile with the latest changes!

@finneyj

This comment has been minimized.

Show comment
Hide comment
@finneyj

finneyj Jan 1, 2016

Contributor

hmmm... I guess it's possible that a change in microbit-dal has forced the inclusion of some of this BLE content event when BLE is compiled out?

Contributor

finneyj commented Jan 1, 2016

hmmm... I guess it's possible that a change in microbit-dal has forced the inclusion of some of this BLE content event when BLE is compiled out?

@dpgeorge

This comment has been minimized.

Show comment
Hide comment
@dpgeorge

dpgeorge Jan 1, 2016

I guess it's possible that a change in microbit-dal has forced the inclusion of some of this BLE content event when BLE is compiled out?

It must be something like that. Or maybe the mbed/nrf modules now include BLE even if it's not used.

dpgeorge commented Jan 1, 2016

I guess it's possible that a change in microbit-dal has forced the inclusion of some of this BLE content event when BLE is compiled out?

It must be something like that. Or maybe the mbed/nrf modules now include BLE even if it's not used.

@finneyj

This comment has been minimized.

Show comment
Hide comment
@finneyj

finneyj Jan 1, 2016

Contributor

yeah... I was wondering the same. I've been talking with the mbed BLE folks about the memory footprint of their libs, and I know they've been actively working on improvements, hence changing the code. It's quite possible that this is a side effect of these changes...

Contributor

finneyj commented Jan 1, 2016

yeah... I was wondering the same. I've been talking with the mbed BLE folks about the memory footprint of their libs, and I know they've been actively working on improvements, hence changing the code. It's quite possible that this is a side effect of these changes...

@finneyj

This comment has been minimized.

Show comment
Hide comment
@finneyj

finneyj Jan 1, 2016

Contributor

I think it's confirmed as something intrinsic to the BLE SDKs. The changes to microbit-dal code were very minor between 1.3.9 an 1.3.10:

lancaster-university/microbit-dal@14831ac

I just unwound the changes on my local build and recompiled micropython, and got the same result - RAM overflow...

We can report this back, but it might take while to get fixed...

Contributor

finneyj commented Jan 1, 2016

I think it's confirmed as something intrinsic to the BLE SDKs. The changes to microbit-dal code were very minor between 1.3.9 an 1.3.10:

lancaster-university/microbit-dal@14831ac

I just unwound the changes on my local build and recompiled micropython, and got the same result - RAM overflow...

We can report this back, but it might take while to get fixed...

@dpgeorge

This comment has been minimized.

Show comment
Hide comment
@dpgeorge

dpgeorge Jan 1, 2016

Surely we can just point to a previous version of the BLE yotta modules?

dpgeorge commented Jan 1, 2016

Surely we can just point to a previous version of the BLE yotta modules?

@finneyj

This comment has been minimized.

Show comment
Hide comment
@finneyj

finneyj Jan 1, 2016

Contributor

not so much form my end. The folks working on the BLE apps needed the latest version of the SDKs urgently, hence this unplanned push, so I can't really revert globally. We can consider doing something specific for micropython builds in the interim though. I'd be supportive of this, but by yotta kung-fu is not so strong beyond the basics. Would you know how we might achieve this purely for micropython builds?

Contributor

finneyj commented Jan 1, 2016

not so much form my end. The folks working on the BLE apps needed the latest version of the SDKs urgently, hence this unplanned push, so I can't really revert globally. We can consider doing something specific for micropython builds in the interim though. I'd be supportive of this, but by yotta kung-fu is not so strong beyond the basics. Would you know how we might achieve this purely for micropython builds?

@finneyj

This comment has been minimized.

Show comment
Hide comment
@finneyj

finneyj Jan 2, 2016

Contributor

OK - I haven't had chance to test, but with a bit of basic trading off of those big static memory allocations in ble-nrf51822, i've got within a gnat's wing of this fitting in (184 bytes short). I think I've shaved off about 800 bytes. With a minor patch to microbit-dal I think I can pull back another 80.

@dpgeorge Any chance of dropping your 10K heap size a little bit? say 9.5K? This should provide a bit of breathing room for your python modules, as these seem to be using a reasonable amount of bss space also.

The alternative would be, as you say, to have micropython refer to older versions of these libraries, but this might lead to incompatibility and maintenance issues for both communities going forward, so i'd rather we stay in sync if at all possible.

What do you think?

Contributor

finneyj commented Jan 2, 2016

OK - I haven't had chance to test, but with a bit of basic trading off of those big static memory allocations in ble-nrf51822, i've got within a gnat's wing of this fitting in (184 bytes short). I think I've shaved off about 800 bytes. With a minor patch to microbit-dal I think I can pull back another 80.

@dpgeorge Any chance of dropping your 10K heap size a little bit? say 9.5K? This should provide a bit of breathing room for your python modules, as these seem to be using a reasonable amount of bss space also.

The alternative would be, as you say, to have micropython refer to older versions of these libraries, but this might lead to incompatibility and maintenance issues for both communities going forward, so i'd rather we stay in sync if at all possible.

What do you think?

@finneyj

This comment has been minimized.

Show comment
Hide comment
@finneyj

finneyj Jan 2, 2016

Contributor

Having slept on this, one alternative is to relax the explicit 2K HEAP limit for the microbit-no-sd target. This might be the preferred option here for a number of reasons:

  • We're within about 100 bytes of this fitting anyway, so the impact is not huge
  • We can apply limit the change to the microbit-nosd target, so it doesn't affect the TD/JS folks at all.
  • it would be a transparent solution from a micorpython perspective, so won't break anything that requires a lot of python HEAP, or updating of core micropython repos.

The downside would be a slightly reduced amount of RAM available on the microbit-dal side, but I expect this will be OK given that you're not running multi-threaded.

I just tried this out on my local build, and now have a working build of micropython based on this approach combined with the optimizations mentioned above.

@dpgeorge Do you agree this is the best way forward? if so, next steps are to:

  • Run a smoke test on the optimizations when BLE is in use
  • Submit a pull request for these changes to Nordic / ARM for future inclusions in the master branch
  • Push an updated version of the microbit-nosd target.

Suggest you also consider some comms on your end to alert the micropython community that they'll need to update the yotta target if they sync to the master branch of microbit-dal....

Thoughts?

Contributor

finneyj commented Jan 2, 2016

Having slept on this, one alternative is to relax the explicit 2K HEAP limit for the microbit-no-sd target. This might be the preferred option here for a number of reasons:

  • We're within about 100 bytes of this fitting anyway, so the impact is not huge
  • We can apply limit the change to the microbit-nosd target, so it doesn't affect the TD/JS folks at all.
  • it would be a transparent solution from a micorpython perspective, so won't break anything that requires a lot of python HEAP, or updating of core micropython repos.

The downside would be a slightly reduced amount of RAM available on the microbit-dal side, but I expect this will be OK given that you're not running multi-threaded.

I just tried this out on my local build, and now have a working build of micropython based on this approach combined with the optimizations mentioned above.

@dpgeorge Do you agree this is the best way forward? if so, next steps are to:

  • Run a smoke test on the optimizations when BLE is in use
  • Submit a pull request for these changes to Nordic / ARM for future inclusions in the master branch
  • Push an updated version of the microbit-nosd target.

Suggest you also consider some comms on your end to alert the micropython community that they'll need to update the yotta target if they sync to the master branch of microbit-dal....

Thoughts?

@dpgeorge

This comment has been minimized.

Show comment
Hide comment
@dpgeorge

dpgeorge Jan 2, 2016

Thanks to @ntoll I managed to inspect a .map file built previous to the RAM overflow issue. In that build the bss is 11976 bytes, compared with 13188 now. In the previous build there is no Gatt stuff, and nothing from the ble-nrf51822 module is linked in.

I'd really like to fix this properly upstream, because there is no reason to have 1k+ of unused bss. Is there anyway we can revert to the previous situation, even locally just by patching some yotta config files by hand?

@finneyj what kind of changes did you make to get 800 bytes back?

Yes I'd like to reduce the size of the mbed heap, but it would be nice if that was in addition to the case where we had 10k to start with. More MP heap gives a much better user experience :)

dpgeorge commented Jan 2, 2016

Thanks to @ntoll I managed to inspect a .map file built previous to the RAM overflow issue. In that build the bss is 11976 bytes, compared with 13188 now. In the previous build there is no Gatt stuff, and nothing from the ble-nrf51822 module is linked in.

I'd really like to fix this properly upstream, because there is no reason to have 1k+ of unused bss. Is there anyway we can revert to the previous situation, even locally just by patching some yotta config files by hand?

@finneyj what kind of changes did you make to get 800 bytes back?

Yes I'd like to reduce the size of the mbed heap, but it would be nice if that was in addition to the case where we had 10k to start with. More MP heap gives a much better user experience :)

@finneyj

This comment has been minimized.

Show comment
Hide comment
@finneyj

finneyj Jan 2, 2016

Contributor

thanks @dpgeorge - that confirms our hypothesis.

Agree we want this fixed upstream, and that we certainly don't want to live with excess bloat.

Just running the numbers more precisely, and with the patches applied we've clawed back 976 bytes of the 1212 bytes lost, which is none to shabby as an interim fix while the ARM/Nordic guys get around to fixing the problem.

The changes are pretty simple - the nrf module has a lot of singleton patterns - and those singletons are statically assigned memory in the bss even if the module isn't initialized. Most of the memory is reclaimed by moving these to lazy instantiation on the heap when required. I'll work up a pull request that i'll apply to the lancaster-university branch of ble-nrf51822 if we want to follow this route.

We can probably revert your builds locally with a bit of work, but it will be incompatible with microbit-dal from this point onwards as the API changed a bit - I had to make a half dozen or so changes due to changes in the BLE APIs.

p.s. now, now, don't be greedy! ;-) With the patch to the no-sd target, the heap will grow/shrink to fit the space between bss and a fixed 2K stack, so if/when this gets fixed upstream, increasing the MP heap would cause the mbed heap to shrink in proportion. Care though - there is no protection from heap/stack collision in mbed, so if you go too small, it will simply start to corrupt itself... which i've seen before. not pretty.

Contributor

finneyj commented Jan 2, 2016

thanks @dpgeorge - that confirms our hypothesis.

Agree we want this fixed upstream, and that we certainly don't want to live with excess bloat.

Just running the numbers more precisely, and with the patches applied we've clawed back 976 bytes of the 1212 bytes lost, which is none to shabby as an interim fix while the ARM/Nordic guys get around to fixing the problem.

The changes are pretty simple - the nrf module has a lot of singleton patterns - and those singletons are statically assigned memory in the bss even if the module isn't initialized. Most of the memory is reclaimed by moving these to lazy instantiation on the heap when required. I'll work up a pull request that i'll apply to the lancaster-university branch of ble-nrf51822 if we want to follow this route.

We can probably revert your builds locally with a bit of work, but it will be incompatible with microbit-dal from this point onwards as the API changed a bit - I had to make a half dozen or so changes due to changes in the BLE APIs.

p.s. now, now, don't be greedy! ;-) With the patch to the no-sd target, the heap will grow/shrink to fit the space between bss and a fixed 2K stack, so if/when this gets fixed upstream, increasing the MP heap would cause the mbed heap to shrink in proportion. Care though - there is no protection from heap/stack collision in mbed, so if you go too small, it will simply start to corrupt itself... which i've seen before. not pretty.

@finneyj

This comment has been minimized.

Show comment
Hide comment
@finneyj

finneyj Jan 2, 2016

Contributor

p.s. can you send me a copy of that .map file?

Contributor

finneyj commented Jan 2, 2016

p.s. can you send me a copy of that .map file?

@finneyj

This comment has been minimized.

Show comment
Hide comment
@finneyj

finneyj Jan 2, 2016

Contributor

oooooh - scratch that. found the bug in ble-nrf51822. There's also an uber god-singleton tucked away in there that was causing the module to be always fully linked. Swapping this for lazy instantiation allows gcc to optimize it out again... This provides a bss of 11856... 120 bytes better off than on @ntoll's build. :-)

I'll work on a minimalist patch to fix this, apply it to the lancaster-university branch and submit a pull request upstream.

Sound good?

Joe

Contributor

finneyj commented Jan 2, 2016

oooooh - scratch that. found the bug in ble-nrf51822. There's also an uber god-singleton tucked away in there that was causing the module to be always fully linked. Swapping this for lazy instantiation allows gcc to optimize it out again... This provides a bss of 11856... 120 bytes better off than on @ntoll's build. :-)

I'll work on a minimalist patch to fix this, apply it to the lancaster-university branch and submit a pull request upstream.

Sound good?

Joe

@finneyj

This comment has been minimized.

Show comment
Hide comment
@finneyj

finneyj Jan 2, 2016

Contributor

@dpgeorge I've updated the ble-nrf51822 module on the lancaster-university repo.

micropython now seems to compile cleanly out of the box again for me, but it would be good if you can provide confirmation?

Contributor

finneyj commented Jan 2, 2016

@dpgeorge I've updated the ble-nrf51822 module on the lancaster-university repo.

micropython now seems to compile cleanly out of the box again for me, but it would be good if you can provide confirmation?

@dpgeorge

This comment has been minimized.

Show comment
Hide comment
@dpgeorge

dpgeorge Jan 2, 2016

@finneyj awesome, thank you! Yes I confirm that it's now compiling for me. Great work.

We'll leave everything else as-is for the moment (uPy heap size, mbed heap size) since it's working quite well and we don't want to be too greedy (just yet!).

dpgeorge commented Jan 2, 2016

@finneyj awesome, thank you! Yes I confirm that it's now compiling for me. Great work.

We'll leave everything else as-is for the moment (uPy heap size, mbed heap size) since it's working quite well and we don't want to be too greedy (just yet!).

@finneyj

This comment has been minimized.

Show comment
Hide comment
@finneyj

finneyj Jan 2, 2016

Contributor

:-) You're more than welcome. You guys are doing some really great work - more than happy to help provide support.

I think you're right about further changes - let's have some stability for a while to make sure everything has bedded in! For info, all the modules on lancaster-university are now versioned and tagged on each release, and I couldn't help but notice that the micropython module.json is just pulling the head revisions.. perhaps you might want to consider tying your releases to a particular revision of microbit-dal and associated libs?

p.s. I'd very much like us to find time to have a talk about how we all intend to provide extensibility for microbit sometime soon (it' s long overdue really!). it may not be possible, but it feels to me that we'd all benefit from having some concept of a shared 'driver model' or something similar, so that all languages can draw on a common set of modules for providing low level support for hardware. I feel it would be a huge win for the project as a whole if we can avoid duplicating work across MP/TD/JS/C... If you'd be interested in exploring the possibilities?

Contributor

finneyj commented Jan 2, 2016

:-) You're more than welcome. You guys are doing some really great work - more than happy to help provide support.

I think you're right about further changes - let's have some stability for a while to make sure everything has bedded in! For info, all the modules on lancaster-university are now versioned and tagged on each release, and I couldn't help but notice that the micropython module.json is just pulling the head revisions.. perhaps you might want to consider tying your releases to a particular revision of microbit-dal and associated libs?

p.s. I'd very much like us to find time to have a talk about how we all intend to provide extensibility for microbit sometime soon (it' s long overdue really!). it may not be possible, but it feels to me that we'd all benefit from having some concept of a shared 'driver model' or something similar, so that all languages can draw on a common set of modules for providing low level support for hardware. I feel it would be a huge win for the project as a whole if we can avoid duplicating work across MP/TD/JS/C... If you'd be interested in exploring the possibilities?

@ncoghlan

This comment has been minimized.

Show comment
Hide comment
@ncoghlan

ncoghlan Jan 4, 2016

I'm happy to confirm that with the latest updates my Docker based build environment now appears to be working.

Next question is a user experience one relating to getting built files out of the container and onto the micro:bit rather than a technical one: ncoghlan/microbit#1

ncoghlan commented Jan 4, 2016

I'm happy to confirm that with the latest updates my Docker based build environment now appears to be working.

Next question is a user experience one relating to getting built files out of the container and onto the micro:bit rather than a technical one: ncoghlan/microbit#1

@finneyj

This comment has been minimized.

Show comment
Hide comment
@finneyj

finneyj Jan 4, 2016

Contributor

cool - thanks for confirming @ncoghlan.

I'm not that familiar with your particular environment, but in the general case, the micro:bit is programmed simply by copying the built .HEX file onto the micro:bit. The device should be presented as a USB file system (like a memory stick) to your system - just drop it on.

Contributor

finneyj commented Jan 4, 2016

cool - thanks for confirming @ncoghlan.

I'm not that familiar with your particular environment, but in the general case, the micro:bit is programmed simply by copying the built .HEX file onto the micro:bit. The device should be presented as a USB file system (like a memory stick) to your system - just drop it on.

@dpgeorge

This comment has been minimized.

Show comment
Hide comment
@dpgeorge

dpgeorge Jan 7, 2016

@finneyj I'm running into RAM problems again. I am updating the uPy module.json file to specify precise versions of the yotta modules. I need to use v1.3.10 of microbit-dal in order to get it to fit in RAM. If I use v1.4.0, v1.4.1 or v1.4.2 then it overflows again (same problem, GattServer is linked in). I'm using the latest version of ble and ble-nrf51822. This is the relevant section of the module.json file:

  "dependencies":{
    "mbed-classic": "~0.0.4",
    "ble": "lancaster-university/BLE_API#v2.1.11",
    "ble-nrf51822": "lancaster-university/nRF51822#v2.2.5",
    "microbit-dal":"lancaster-university/microbit-dal#v1.3.10"
  },

The above works. If I bump microbit-dal to any of the v1.4 versions then it doesn't work. Any ideas?

dpgeorge commented Jan 7, 2016

@finneyj I'm running into RAM problems again. I am updating the uPy module.json file to specify precise versions of the yotta modules. I need to use v1.3.10 of microbit-dal in order to get it to fit in RAM. If I use v1.4.0, v1.4.1 or v1.4.2 then it overflows again (same problem, GattServer is linked in). I'm using the latest version of ble and ble-nrf51822. This is the relevant section of the module.json file:

  "dependencies":{
    "mbed-classic": "~0.0.4",
    "ble": "lancaster-university/BLE_API#v2.1.11",
    "ble-nrf51822": "lancaster-university/nRF51822#v2.2.5",
    "microbit-dal":"lancaster-university/microbit-dal#v1.3.10"
  },

The above works. If I bump microbit-dal to any of the v1.4 versions then it doesn't work. Any ideas?

@finneyj

This comment has been minimized.

Show comment
Hide comment
@finneyj

finneyj Jan 7, 2016

Contributor

Thanks @dpgeorge.

Looks like a #ifdef a little out of place in the recently merged secure-ble branch, @jamesadevine is working on a patch for you now. Thanks for letting us know. Should be fixed in 1.4..3.

Contributor

finneyj commented Jan 7, 2016

Thanks @dpgeorge.

Looks like a #ifdef a little out of place in the recently merged secure-ble branch, @jamesadevine is working on a patch for you now. Thanks for letting us know. Should be fixed in 1.4..3.

@jamesadevine

This comment has been minimized.

Show comment
Hide comment
@jamesadevine

jamesadevine Jan 7, 2016

Contributor

@dpgeorge there is a config option related to BLE that has gone awry.

If you set #define MICROBIT_BLE_PAIRING_MODE to 0 in your config, you will get your ram back.

Contributor

jamesadevine commented Jan 7, 2016

@dpgeorge there is a config option related to BLE that has gone awry.

If you set #define MICROBIT_BLE_PAIRING_MODE to 0 in your config, you will get your ram back.

@jamesadevine

This comment has been minimized.

Show comment
Hide comment
@jamesadevine

jamesadevine Jan 7, 2016

Contributor

@dpgeorge Well that comment was incorrect.

The config should always be set like that as pairing could be performed regardless of the BLE_ENABLED config option.

This allows users to run their apps with all of RAM available, and also allows for remote programming.

Contributor

jamesadevine commented Jan 7, 2016

@dpgeorge Well that comment was incorrect.

The config should always be set like that as pairing could be performed regardless of the BLE_ENABLED config option.

This allows users to run their apps with all of RAM available, and also allows for remote programming.

@finneyj

This comment has been minimized.

Show comment
Hide comment
@finneyj

finneyj Jan 7, 2016

Contributor

ahh.., thanks @jamesadevine. That explains it.

We do keep these options separate so that it's possible to run apps that don't use BLE (so can utilize the additional 8K-10K of SRAM that this enables), yet can be programmed over the air when needed. e.g. from a phone / table that doesn't have USB.

@dpgeorge - I presume it's ok for you to add this extra config option to the local MicroBitCustonConfig.h for micro-python?

Contributor

finneyj commented Jan 7, 2016

ahh.., thanks @jamesadevine. That explains it.

We do keep these options separate so that it's possible to run apps that don't use BLE (so can utilize the additional 8K-10K of SRAM that this enables), yet can be programmed over the air when needed. e.g. from a phone / table that doesn't have USB.

@dpgeorge - I presume it's ok for you to add this extra config option to the local MicroBitCustonConfig.h for micro-python?

@dpgeorge

This comment has been minimized.

Show comment
Hide comment
@dpgeorge

dpgeorge Jan 7, 2016

Thanks guys, it works now with that config option set explicitly to 0 in MicroBitCustomConfig.h.

dpgeorge commented Jan 7, 2016

Thanks guys, it works now with that config option set explicitly to 0 in MicroBitCustomConfig.h.

@finneyj

This comment has been minimized.

Show comment
Hide comment
@finneyj

finneyj Jan 7, 2016

Contributor

cool. :-)

@dpgeorge - probably not relevant, but thought I'd mention. If you had enough FLASH to hold soft device, could use this interface to allow micro-python to do over the air programming with BLE, but then have BLE disabled for when micro-python is running...

You;d have to take the ~100KB flash hit of SoftDevice though, so this is probably not feasible for you, but thought I'd mention it!

Contributor

finneyj commented Jan 7, 2016

cool. :-)

@dpgeorge - probably not relevant, but thought I'd mention. If you had enough FLASH to hold soft device, could use this interface to allow micro-python to do over the air programming with BLE, but then have BLE disabled for when micro-python is running...

You;d have to take the ~100KB flash hit of SoftDevice though, so this is probably not feasible for you, but thought I'd mention it!

@dpgeorge

This comment has been minimized.

Show comment
Hide comment
@dpgeorge

dpgeorge Jan 7, 2016

Yes, that would be nice to have BLE upgrade. Our binary is just under 200k at the moment (yes big!) so we can't afford 100k unless we cut out some features (eg floating point support, which I think is very useful).

dpgeorge commented Jan 7, 2016

Yes, that would be nice to have BLE upgrade. Our binary is just under 200k at the moment (yes big!) so we can't afford 100k unless we cut out some features (eg floating point support, which I think is very useful).

@finneyj

This comment has been minimized.

Show comment
Hide comment
@finneyj

finneyj Jan 7, 2016

Contributor

@dpgeorge, yes, floating point sounds like a better trade off.

Perhaps just one to keep in mind, in case if we ever have any more flash memory available on future hardware. ;-)

Contributor

finneyj commented Jan 7, 2016

@dpgeorge, yes, floating point sounds like a better trade off.

Perhaps just one to keep in mind, in case if we ever have any more flash memory available on future hardware. ;-)

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