サンプルプログラム「ble_app_uart」が動作しない。

[yokokawa]

[Ble_app_uart] of the old version of [nRF5_SDK_14.2.0_17 b948 a] is operating correctly, not due to the low-speed clock.
In the old version, the operation of the crystal setting has been confirmed.
The product also confirms the operation of CR calling for CR transmission.
Only the new version does not work.

[yokokawa]

「nRF5_SDK_15.0.0_a53641a」を使用しています。

[yokokawa]

I am using Taiyo Yuden 's EBSHSNZWZ.

"Ble_app_uart" of the sample program "nRF5_SDK_15.0.0_a53641a" was executed, but the program locked up.
* There is no error or warning.
※ The sample program has not been changed.
Contents:
When executed, nrf_sdh_enable_request () in main will stop at execution.
It seems that it will not come back from ret_code = sd_software_enable (& clock_lf_cfg, app_error_ fault_handler) in nrf_sdh_enable_request ().

Please tell me the possible causes.
※ It works normally with nRF5_SDK_14.2.0_17b948a.
* Since I want to communicate 244 bytes by BLE, I made it to a new version, if there is a method that can be realized with the old version, please also show that way.

Thanking you in advance.

[rraa]

There may be errors in SDK 15. Nordic engineers will respond to this.

[Stian Røed Hafskjold]

Hmm. this sounds weird to me. So as far as I understand, you know that the LF crystal is working and also that the UART pinout is correct because it is working with SDK14?

I don't have the Taiyo Yuden board here so I'm not able to test. But can you try another example on SDK 15, disable any GPIO pins, and also use the LF RC instead of the crystal. Just so we can try and see where the problem lies. Thanks!

[yokokawa]

The problem was solved.
There was a problem with Taiyo Yuden's evolution board.
Thank you very much.