まだnRF51822でSoftDeviceの初期化がうまくいっていない。
うーむ。。。
とりあえず、コメントの解釈を間違っていたことだけはわかったので、メモ。
解決にはならないんだけどね。
* @note Some care must be taken if a low frequency clock source is already running when calling this function:
* If the LF clock has a different source then the one currently running, it will be stopped. Then, the new
* clock source will be started.
「先にLFCLKを動かしてないといかん」と思っていたが「先に動かしていた場合は以下を気をつけろ」だった。
ってことは、動かさなくていいんだ。
そして、それは最初と同じ話に戻るということで、結局はここで固まっているという・・・。
うーん、HFCLKは外部CLKで動作させ、LFCLKは止めたままで呼んでみるか。。
32kの外部クロックが接続されていないのが原因と思われます。
返信削除クロックソースをNRF_CLOCK_LFCLKSRC_RC_250_PPM_250MS_CALIBRATIONなどにすれば動きます。
コメントありがとうございます。
削除すみません、前ブログの続きだったため、設定を載せていませんでした。
SOFTDEVICE_HANDLER_INIT(NRF_CLOCK_LFCLKSRC_RC_250_PPM_4000MS_CALIBRATION, false);
いわれているように、外部32Kは接続していません。
単独でLFCLKを動かしたときには、EVENTS_LFCLKSTARTEDが立つので、内蔵32Kは発振してるんじゃないかな、と思ってます。
とはいえ、動いてないのは事実なので、まだ間違ってるのかもしれませんが・・・。
なるほど、失礼しました。
返信削除そしたらNVICでしょうか。
softdevice_handler_initを呼ぶより先にNVIC_EnableIRQ()で何かの割り込みを有効化するとその関数から帰ってこれないことがありました。
解決しました！
削除書き込まれていたSoftDeviceのバージョンが違っていました。
仕様書に6.0.0と書いてあったのですが、実際には5.2.1でした。
バージョンの違いでenumの順番が変わっていて、6.0.0のNRF_CLOCK_LFCLKSRC_RC_250_PPM_4000MS_CALIBRATIONは5.2.1ではNRF_CLOCK_LFCLKSRC_XTAL_20_PPMに相当していて、結果として外部32Kを動かそうとしていた、ということになります。
ですので、現象としてはご指摘の内容が発生していました。
コメントいただいて、やはりクロックを疑うべきという視点で眺めていったので、比較的早く見つかりました。
ありがとうございます。
顛末は、こちらに。
http://hiro99ma.blogspot.com/2014/06/ble.html