This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Unable to run "BLE Blinky" on an Fanstel BM832A but can run non-BLE examples

I'm sure the mistake is mine but I would appreciate some suggestions on where to look for my mistake.

I have a custom board with a Fanstel BM832A module.  I also have an NRF52 dev kit for comparison.

I can run basic non-bluetooth peripheral code on the board so I know I have good SWD programming.

I am starting from the example at nRF5_SDK_17.0.2_d674dde\examples\ble_peripheral\ble_app_blinky\pca10040e\s112\armgcc.  I am using the same version of GCC as that version of the SDK's makefile specifies.

Building that example runs exactly as expected on the NRF52.  I can change the name of the device and interact with it over bluetooth.

However, I am so far unable to successfully modify the makefile to run on my "real" NRF52810.

Here's what I have tried without luck:

  1. Defined a custom board.  I could have button and LED pins wrong but I can't see anything on BLE so I don't think a mistake here would explain that.
  2. Removed "CFLAGS += -DDEVELOP_IN_NRF52832" (and the same ASMFLAGS)
  3. Removed "CFLAGS += -DNRF52_PAN_74" (and the same ASMFLAGS)
  4. Removed "CFLAGS += -DNRFX_COREDEP_DELAY_US_LOOP_CYCLES=3" (and the same ASMFLAGS)

execute make, make flash, make flash_softdevice and I see nothing on BLE.  

Any suggestions of what to try next?  

Thank you,

David

Parents
  • So starting to see the big picture I think but still not working...  

    It appears to me that Fanstel intends this module to be used a BLE transceiver for another microcontroller.  They ship it with a default image loaded and documentation for interfacing their module to another microcontroller over SPI or UART using AT commands.

    So I'm not saying what I want to do (run custom code) is impossible, it is just not documented or supported by Fanstel.  I have scoured their website and Google and to the best of my abilities there is no source code provided at all for this module.

    It is an NRF52810 module with no external oscillator.  So that means (I think) I have 3 basic tasks at least to port a PCA100040e example

    1. The porting steps listed in the SDK at https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.0.2/nrf52810_user_guide.html?cp=7_1_5_0
    2. Change the sdk_config.h as outlined by hmolesworth
    3. Somehow start / enable the RC oscillator in code.  I tried a blind paste of hmolesworth code into my source but it did not work.

    I think I am doing steps 1 and 2 right but don't know how yet to do step 3 or if I am missing anything else.  

    David

  • First I see that you didn't mention an Erase All followed by a power-on reset step; did you do that before programming the softdevice followed by the application? This is necessary for all these modules (and the uBlox/Rigado modules) to completely clear the delivered settings otherwise BLE does not work. If you need to keep the delivered MAC address then read that out first. Both Segger SES (Target->Connect, Target->Erase All) and nRFGo Studio (even though the latter is now depreciated) work fine for this. I repeat; without an erase all BLE will not work on a newly delivered module. If protection is enabled, a recover may be necessary first. The nRFConnect and command line tools may also be used, but I use the above

    I had a look at the development board for that module, but it is confusing as the schematic shows an nRF52840 module. Some of their development boards provide an external 32kHz crystal I see, but the module should work fine without, using the settings I gave. I have tested this on the uBlox/Rigado BMD350 module, which is identical in terms of functionality and MCU and is also delivered with pre-loaded software which causes BLE to not work when using the normal SD/app project build-and-debug cycle.

Reply
  • First I see that you didn't mention an Erase All followed by a power-on reset step; did you do that before programming the softdevice followed by the application? This is necessary for all these modules (and the uBlox/Rigado modules) to completely clear the delivered settings otherwise BLE does not work. If you need to keep the delivered MAC address then read that out first. Both Segger SES (Target->Connect, Target->Erase All) and nRFGo Studio (even though the latter is now depreciated) work fine for this. I repeat; without an erase all BLE will not work on a newly delivered module. If protection is enabled, a recover may be necessary first. The nRFConnect and command line tools may also be used, but I use the above

    I had a look at the development board for that module, but it is confusing as the schematic shows an nRF52840 module. Some of their development boards provide an external 32kHz crystal I see, but the module should work fine without, using the settings I gave. I have tested this on the uBlox/Rigado BMD350 module, which is identical in terms of functionality and MCU and is also delivered with pre-loaded software which causes BLE to not work when using the normal SD/app project build-and-debug cycle.

Children
No Data
Related