This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Runtime failure with ble_app_beacon_bcs project on beacon HW

I've got 3 of the 51822 kits: smart beacon, m-kit, and eval-kit.

I've successfully installed Keil uVision 5.1 and developed/loaded applications for eval-kit. I've successfully run and built the applications for the m-kit using mbed.org.

However, when trying to develop code for the beacon, I can't get anything to run successfully on the beacon.

Attempt 1: using the project ble_app_beacon_bcs This project compiles/builds fine, however after loading the hex on the beacon, Outcome: the beacon light (instead of flashing purple) will flicker ever so slightly, unless the SW1 is pressed -- where it goes solid green.

Attempt 2: change the source of ble_app_beacon_bcs, to do some very basic thing, like turn on the LED at boot for extended period of time (comment out all other source for advertisement). Same outcome as above.

Attempt 3: build a simple/basic application for 81522 on mbed.org and upload to beacon hw. Outcome: Master Control panel doesn't even attempt to upload it to the device; just disconects immediately. Now I would expect that an application build from mbed would probably not work due to differences in default HW config.

Attempt 4: import and attempt to build the BLE_beacon project on mbed.org. Outcome: this appears much different then the ble_app_beacon_bcs project as it is C++ based, and equivalently, doesn't build out of the box on mbed.org.

Overall, I expect that the ble_app_beacon project should work fine when loaded, but can't seem to successfully load anything but the pre-compiled .hex on the HW.

I wonder if possible errors are:

  1. loading issues when using the Master Control Panel via Android device. I don't believe this is the case, as when I load the "precompiled ble_app_beacon.hex" back on the device, it returns to normal operation.

  2. there are differences in the ble_app_beacon_bcs project then the precompiled .hex, and the project isn't properly setup for my HW.

Perhaps someone can shed some light or further debugging tips?

  • To make this question simple,

    Can anyone confirm that compiling the source: ble_app_beacon_bc and loading it on the beacon hardware works just the same as the pre-compiled .hex that Nordic provides?

  • FormerMember
    0 FormerMember

    A hex file compiled from ble_app_beacon_bcs should have the exact same functionality as the pre-compiled ble_app_beacon.hex. I have followed the exact same procedure as you describe for uploading the beacon firmware, with a hex file generated from the source code. It seems to work fine!

    I have attached the hex file generated from the beacon source code ble_app_beacon_bcs. Could you try to upload/program this file to your beacon device and check if it works?

    Attachment: ble_app_beacon_from_source_code.hex

    Edit: It should not be necessary to have the SDK installed in order to compile the code that comes with the beacon kit.

    The problem may have been related to the IROM and IRAM settings. These settings depends on the softdevice that is being used with the application. The beacon kit v. 1.0.1 firmware should be used with softdevice S110 v.6.0.0, and the IROM and IRAM settings should be the following: image description

    How the IROM and IRAM setting are found is explained in chapter 6.2.1 in the nRF51822 development kit user guide.

    The difference between the targets, PCA10001, PCA10000, PCA10024, etc, is the mapping of which GPIO pins on the specific board that is used for the buttons, LEDs, UART, etc. Remember that the chip (nRF51822) on the different boards is the same.

  • Thanks for your confirmation --

    I can confirm after uninstalling Keil and the Beacon SDK (firmware 1.0.1), and reinstalling I can confirm that this is now working by compiling the out-of-the-box application. I am using Keil v5.11.1.0 (Lite), nRF51822_beacon_firmware_1.0.1.msi, and the SDK (nrf51_sdk_v6_1_0_b2ec2e6). This is loaded to the beacon via OTA from the PCA10000 (USB) dongle on Win64.

    Because there isn't a Keil uVision 5 version of the project included -- I suspect there were problems with the installed SDK/library support. Unclear -- as I never got it to work on earlier SDKs.

    What would be "really" helpful is understanding what "options" are necessary to compile/link code between the different HW platforms. Currently, I'm trying to make a project which includes the different targets: PCA10000, PCA10001, PCA10024, and PCA20006.

    uVision5 projects contain the "CMSIS" and "Device" under the "Project" window, but the ble_app_beacon.hex (after conversion to uVision5) doesn't contain these items.

    Assuming we've got the proper #define for board type and boards.h included, I'm stuck trying to figure out the differences in the "Options for Target" are so that the same code will compile successfully on all HW. Is there a reference to proper settings for values like: IROM1, IRAM1 and whether or not the Assembler control strings (SDK\arm\RTE) versus (Keil_v5\ARM\RV31\INC) are potential reasons for these applications behave badly?

    Is there a sample project (or doc) which includes the HW targets and proper settings for each?

    Thanks again!

  • Confirmed the majority of the problem with fast "blinking LEDs" is due to:

    • when the application runs into an error, it goes to APP_ERROR, which resets the device
    • if the application runs into an error during init, there is an infinite "reset" loop created by this process.

    Because its hard to debug the beacon (without additional hw) it wasn't clear whether there were actually runtime failures, incorrect setup, or just this application reset loop.

    This thread (thanks to Krisitin for her help) confirms:

    • beacon runs SoftDevice 6, and the IRAM/IROM settings for all devices running v6.
    • beacon application is portable to devkit board running SDv6
    • application changes causing error during init cause this 'reset loop' behaviour described
Related