Copyright ©

Mongoose OS Forum

ATTENTION! This forum has moved to:

Do not post any new messages.

CC3200 and I2C. Can no longer specify pin numbers in mos.yml

ulsoulso Stockholm

I have this mos.yml contents:

name: mygw
arch: cc3200
version: 1.0
skeleton_version: 2017-05-18
  - src
  - fs
  - ["i2c.enable", true]
  - ["i2c.freq", 100000]
  - ["i2c.scl_pin", 16]
  - ["i2c.sda_pin", 17]
  - origin:
  - origin:
  - origin:
  - origin:
  - origin:
  - origin:
  - origin:
  - origin:
  - origin:
  - origin:
  - origin:
  - origin:
  - origin:

When building I now get error messages complaining about the setting of i2c.scl_pin.

While parsing /tmp/fwbuild-volumes/users/test/mygw/build_requests/build_req_584583653/build/gen/mos_conf_schema.yml: 'i2c.scl_pin: Cannot override, no such entry'
While parsing /tmp/fwbuild-volumes/users/test/mygw/build_requests/build_req_584583653/build/gen/mos_conf_schema.yml: 'i2c.scl_pin: Cannot override, no such entry'
/mongoose-os/fw/src/ recipe for target '/tmp/fwbuild-volumes/users/test/mygw/build_requests/build_req_584583653/build/gen/sys_config_schema.json' failed
make: *** [/tmp/fwbuild-volumes/users/test/mygw/build_requests/build_req_584583653/build/gen/sys_config_schema.json] Error 1


  • rojerrojer Dublin, Ireland

    I2C support has been factored out into a lib, add the i2c lib to your list

  • ulsoulso Stockholm

    I tried that. Didn't work. Then I discovered that the i2c lib was already included by the rpc-service-i2c lib, so I removed it from my mos.yml.

  • ulsoulso Stockholm

    Added i2c back again. See the complete response from mos build attached.

  • Thanks for reporting, reproduced, fixing. Will let you know when it's done

  • I am having the same issue. It was working yesterday, broken today.

    We are finding this sort of thing difficult when using Mongoose for production development, as our working build for one day stops working the next. The production embedded systems needs a solid, fixed, tested platform which is held at least during the development cycle of the product.
    Can you make working versions of Mongoose available while you develop new versions on a separate branch?

  • edited June 2017

    Yes, sorry about that, we're currently working on separation of mOS functionality into libs, and this is still very fresh. However, you can pin to a specific version of mOS core and libs; the latest is 1.4. So, in your mos.yml, please add this:

    mongoose_os_version: 1.4 # use tag 1.4 for
    libs_version: 1.4        # use tag 1.4 for all libraries

    This way, your build will stay exactly the same unless you unpin it.

    Also, please remove/comment those libs, because they didn't exist when 1.4 was released:

    - origin:
    - origin:
    - origin:
    - origin:
    - origin:
  • SergeySergey Dublin, Ireland as @dimonomid suggested, please pin your code to a specific mongoose OS version and use a local build.
    This way you're guaranteed to have a stable environment.
    As time goes, you can roll forward to the newer versions.

  • Yes, but this is the challenge "and use a local build"
    Those issues are for another thread...

  • Actually, using a local build is not really necessary: as long as you have mongoose_os_version and libs_version specified, remote build will pick exactly those versions for you.

    In theory, there is a possibility that the format of mos.yml will change in such a major way so that we'll drop backward compatibility for that, and remote builder will refuse to accept your mos.yml, but it's highly unlikely to happen in any near future.

    So, as I said in my comment above, add those two keys with versions, remove a few libs which were not present when 1.4 was released, and build it remotely.

  • edited June 2017

    The fix has been pushed to the remote build service, now it should work fine.

    Sorry once more for that inconvenienсe. We're considering pinning our apps and examples to some branch other than master by default.

  • Thank you and please do consider "pinning our apps and examples to some branch other than master".
    We will be using mongoose_os_version and libs_version - which is very good news.

  • I had the same problem. I2C was working yesterday, and today it seems to be broken.
    I followed the recommended steps above... tagged my os version to 1.4.
    I did the same with the lib version.
    When I build, i get the following error:

    "http-server-1.4" does not exist, cloning... 
    Error: failed to git checkout 1.4: exit status 1
    Error: build failed

    This is bad, because yesterday I had to add http-server as a library or else "mgos_get_http_endpoint" is no longer recognized as a valid function in which case my build fails.
    So the solution above does not work for me.

  • @only1chi , I believe you missed the second part of the solution, as I wrote above:

    Also, please remove/comment those libs, because they didn't exist when 1.4 was released:

    - origin:
    - origin:
    - origin:
    - origin:
    - origin:

    In mongoose-os 1.4, this functionality is in the core.

  • only1chionly1chi Boston
    edited June 2017

    So I did remove the reference to:

    - origin:

    This was the only library I was referencing from yesterday's build.
    I had a problem with my build yesterday where the function "mgos_register_http_endpoint" was no longer recognized. After posting on this forum for help, @Sergey suggested that I include the library :smile: - origin:

    I did this and my project was compiling yesterday. However, today its no longer compiling due to the changes made in the "master" repository.
    Following the recommendations above, I tagged the os_version and lib_versions to 1.4. However since - origin: is not in lib_versions 1.4, I'm back to the same problem I had yesterday where mgos_register_http_endpoint is not recognized.

    So what are my options at this point?

  • @only1chi , if you use mongoose_os_version: 1.4 in your mos.yml, then mgos_register_http_endpoint will be in the core (declared in fw/src/mgos_mongoose.h), no extra libs are needed for that. I just verified that, it worked.

    Please share the whole app sources that you're trying to compile (e.g. attach a zip file), I'll take a look.

  • ulsoulso Stockholm

    @dimonomid , thanks for the fix. Works fine for me now.

  • Hi @dimonomid please see attached source 23.2K
  • @only1chi, see attached with the fixed sources.

    Changes I've made:

    in mos.yml:

    • you have both mongoose_os_version: master and mongoose_os_version: 1.4; since the latter comes last it wins, but still it might be confusing, so I removed the first line
    • you have libs_version: 1.4 commented; I uncommented it
    • you have lib included, I commented it

    in src/main.c:

    • There is #include "mgos_http_server.h"; in 1.4 the right header is #include "fw/src/mgos_mongoose.h"
    • Commented the usage of non-standard tm_zone and tm_gmtoff (you might prefer to solve that differently, but that's just unrelated to the http-server problem we're discussing, so I took the quickest shortcut)

    After that, mos build succeeds.

  • It is working this morning...
    I did remove all the references to the libraries, and made no modifications to my code.
    Can't explain it.

  • Thanks @dimonomid

  • @only1chi np, glad it's resolved for you. Not sure what exactly did not work before but works now; if you mean i2c.scl_pin on the latest revision of mOS and libs (without pinning them to 1.4), then yes, it was fixed yesterday after the initial bug report.

  • , fyi, release policy of Mongoose OS has been finally updated.

    As you know, the problem was that the changes we deploy to mongoose-os were immediately observable by the users' builds, so it happened a few times that after some API change, the build which worked yesterday becomes broken today.

    This is not going to happen anymore: starting from version 1.7, the code never changes under your feet unless you explicitly ask for an update. You can perform an update right now: do mos update release or mos update 1.7, then make sure your app's manifest has this:

    libs_version: ${mos_version}
    modules_version: ${mos_version}
    mongoose_os_version: ${mos_version}

    And after that, your code will always be compiled against version 1.7 (all components of mongoose-os are pinned to that version number: the core and all libraries).

    When a newer version becomes available (say, 1.8), your build will still be done against 1.7, you'll just get a notice after the build:

    There is a newer version available: "1.8" (you use "1.7"). Please consider upgrading.

    But it's always up to you whether to update or not. You might give it a try: mos update release or mos update 1.8, and if 1.8 makes you unhappy for any reason, you can always go back to 1.7: mos update 1.7. It's that easy.

    For those willing to stay on bleeding edge latest version, there is of course mos update latest.

Sign In or Register to comment.