Hi Thiago, I assume, you mean, you are using nRF52832 chip and your custom board; and using a Zephyr build using the BOARD=nrf52_pca10040. Do you have the 32KHz crystal mounted in your custom PCB? If

Hi, I can help you if its an issue with BLE, can you give details of the application you are using and the symptoms of the issue? I have no experience myself with OpenOCD, I always have used our DK bo

Nice! May I ask if there where any preceding console messages? usually, the assert condition is printed along with the function name. -Vinayak

Hi Scott, If I where to force an assert (break the design), this is how I would get (for samples/bluetooth/peripheral on my local repo): [bt] [INF] show_dev_info: Identity: da:d7:35:42:55:80 (random)

[vich] Are you using the upstream master as-is? Or you have modified the default configurations? BT_ERR message when ASSERTing should be printed out on UART by default for the peripheral sample.

Ah… I see your revision is older than a controller regression fix done in cb90fbe56. The symptom was the exact assert as you see, around ~8 mins interval from power up. Please use latest revision and

Hi Steve, Yes, we (for myself) are listening ;-) You say beacon hex flashed to ble nano2 works (advertises). 1. Does hello world sample work (print out on UART)? 2. Does the samples/basic/blinky work

Ok, so the CPU and UART works :-) And, the 32KHz clock domain works, hence the blinks. Now, CPU can run from internal High Frequency RC or External crystal. If your 32MHz crystal on the board has dry

Commented in the PR. We can discuss further there. Thank you for your analysis. -Vinayak

Hi Ashish, Did you select CONFIG_I2C_NRF5 in menuconfig or set CONFIG_I2C_NRF5=y in prj.conf file? Also, you need to set CONFIG_I2C_NRF5_GPIO_SCA_PIN , CONFIG_I2C_NRF5_GPIO_SCA_PIN ,CONFIG_I2C_0=y, an

Its: fs_file_t my_zfp; // no * please; and fs_open(&my_zfp,"mesh.prv"); // & please J That said, I am not expert on FS! -Vinayak

Hi Vikrant, Please try the PWM without the BT Controller included. There could be some PWM regression due to changes in controller implementation. That said the nrf5_sw driver is software variant desi

Hi Vikrant, I have run the upstream fade_led sample on nrf52840-PDK, I see no regression, the brightness changes every second (up and then down so on). I advice you to debug your implementation as I h

Hi Vikrant, As i said, there is possible overlap of PPIs with BT Controller. PPI channel 16 and 17 overlap with Code PHY feature in nRF52840. I will try to send a PR wherein you could (correctly) disa

Your main.c uses pwm_nrf5_sw.c driver which has conflict with BT features on nRF52840... I do not see use of NRF_PWM0 in you main.c, of course, yes your code in the devzone does, hope you get some hel

Hi Vikrant and Neves, I have submitted a PR that will correctly “disable” Coded PHY support in nRF52840, in turn avoiding the PPI channels 14 to 19 and hence usable by pwm_nrf5_sw.c implementation. Us

Hope you are doing it “only once per board’s life time” else you could be degrading the flash. Hence, my advice is to use nrfjprog to make the change "only once" per each board or use the design in so

1. Correction, values in UICR are at fixed location, changing them is not needed on every power up of the board.That said, after a change, a power cycle is need for h/w to load the new values. And yes

Hi, This e-mail is only for information. In a recent email chain, I had mentioned nRF Sniffer. If you own a nRF51 dongle/DK or nRF52832 PCA10040 DK, you have a free simple Bluetooth Low Energy packet

Hi Vikrant, The Zephyr BLE controller does not implement the Tx power set interface in the upstream code, hence Zephyr controller operates with +0dBm transmit power. Feel free to supply the correct h/