nRF52832 Internal Oscillator Softdevice Enable Hanging [closed]

ConfusedIndividual gravatar image

asked 2017-04-21 18:31:31 +0100

I'm using the nRF52832 chip without an external crystal. I configured it to use the internal RC with:

nrf_clock_lf_cfg_t clock_lf_cfg;
clock_lf_cfg.source = NRF_CLOCK_LF_SRC_RC;
clock_lf_cfg.rc_ctiv = 16;
clock_lf_cfg.rc_temp_ctiv = 2;
clock_lf_cfg.xtal_accuracy = 0;

// Initialize SoftDevice.

However, the device seems to be hanging upon enabling the SoftDevice. When going through with a debugger, it just jumps to address 0 continuously. I have the Monitor Mode debugging set up based on the blog post, so I wouldn't think that would be the issue.

Am I doing something wrong in configuring the Softdevice to use the Internal RC?

edit retag flag offensive reopen delete report spam

Closed as "the question is answered, right answer was accepted" by Definitely Confused at 2017-05-12 17:52:43 +0100


Have you tried regular debugging and checking if you are running into the error-handler? See this post on how to debug. That the address jumps to 0 continuously indicates that the device is restarting (default behavior when running into the error-handler.)

Sigurd ( 2017-04-21 18:49:12 +0100 )editconvert to answer

I had a fault every time I tried to start with temp_ctiv. Seems like it might be a bug in some SD's. Try setting temp_ctiv to 0. If you are running on the internal RC, then likely RTC accuracy isn't supremely important. So a calibration cycle every 4 seconds will be sufficient. The temp measurement isn't that important.

AmbystomaLabs ( 2017-04-21 20:19:13 +0100 )editconvert to answer

I'm seeing it reset to 0, even if I set the temp_ctiv to 0. Even with regular debugging, I'm not seeing it hit any error handlers. I've put breakpoints in app_error and softdevice_handler and I'm not seeing anything.

Definitely Confused ( 2017-04-26 16:57:53 +0100 )editconvert to answer

Did you remember to add DEBUG as a Preprocessor symbol?

Sigurd ( 2017-04-26 17:00:39 +0100 )editconvert to answer

Yes, I added DEBUG is a preprocessor symbol. If I go through with the debugger step by step, I can eventually reach the error handler, but just hitting "Continue" always jumps me back to 0

Definitely Confused ( 2017-04-26 17:02:39 +0100 )editconvert to answer

Have you tried starting it without the app scheduler? I haven't ever used the scheduler but my understanding is that it only affects the way interrupts are handled and provides more resources to main. Assuming you aren't running gobs of code in handlers, you should get plenty of time back at main to run housekeeping even without the scheduler.

So try:

#define NRF_CLOCK_LFCLKSRC {.source = NRF_CLOCK_LF_SRC_RC, \ .rc_ctiv = 16, \ .rc_temp_ctiv = 0}

nrf_clock_lf_cfg_t clock_lf_cfg = NRF_CLOCK_LFCLKSRC;


AmbystomaLabs ( 2017-04-26 18:39:20 +0100 )editconvert to answer

I haven't tried without the handler, but I use the scheduler for the app_timer. Do I need to use it with the softdevice as well?

Definitely Confused ( 2017-05-03 20:33:15 +0100 )editconvert to answer

Please clarify your comment. Do you need to use what with the soft device?

AmbystomaLabs ( 2017-05-03 20:49:15 +0100 )editconvert to answer

Do I need to use the scheduler with the softdevice? If I use the scheduler for the app_timer, am I required to use the scheduler with the softdevice?

Definitely Confused ( 2017-05-03 21:03:30 +0100 )editconvert to answer

No the scheduler is not required with the soft device. And, app scheduler is not required for the app_timer. For this reason I suggest you try starting the soft device without the scheduler as shown in my comment on 4/26. It could just be the scheduler causing your problem.

Here is some additional info on the app_timer and also the app_scheduler: https://devzone.nordicsemi.com/tutori...https://devzone.nordicsemi.com/tutori...

AmbystomaLabs ( 2017-05-03 21:48:59 +0100 )editconvert to answer

I stopped using the scheduler with the softdevice and I still see the problem. I'm open to this being a hardware problem. Is there a good way to check that?

Definitely Confused ( 2017-05-08 20:05:55 +0100 )editconvert to answer

Well we would need to review your schematic. If you are not happy with one of the regulars on this site reviewing it (such as me) then I know Nordic has a private review process. Also I think we should see your source code. There could still be a problem there. Let me know. I'm happy to assist.

AmbystomaLabs ( 2017-05-08 20:19:53 +0100 )editconvert to answer

Have you tried your code on one of the development kits? Or, are there too many hardware requirements such that it wont' run on a standard DK?

AmbystomaLabs ( 2017-05-08 20:21:48 +0100 )editconvert to answer

Could you double check that the 32 MHz crystal on your board is mounted correctly, i.e. not shifted by 90 degrees for example?

Is the chip resetting? Resets at runtime are in almost all cases caused by code asserts ( error handler calls nvic_systemreset()). You can check NRF_POWER->RESETREAS on startup if you want to check what the reset source was.

Sigurd ( 2017-05-09 11:20:45 +0100 )editconvert to answer

We don't have a 32MHz crystal mounted on the board. We wanted to conserve board space. The reason states soft reset and chip lockup (I see NRF_POWER->RESETREAS = 0x1100 [12]), but I see from other threads that the lockup bit is not to be trusted when set alongside along bits. I have the DEBUG macro defined, so I thought it wouldn't be calling the system reset function

Definitely Confused ( 2017-05-09 15:59:06 +0100 )editconvert to answer

Ah, there was the missing bit!

In your original question you only mentioned the missing RTC. You can run the SD without an RTC but you cannot run it without a 32MHz. That is your problem.

AmbystomaLabs ( 2017-05-09 16:12:52 +0100 )editconvert to answer

As mentioned in the "General PCB design guidelines for nRF52" tutorial:

An external 32 MHz crystal is mandatory, and an external 32 kHz crystal is optional

The external 32 MHz crystal need to have max ±40 ppm. On the nRF52832-DK the 32MHz crystal is ±10 ppm.

Sigurd ( 2017-05-09 17:21:59 +0100 )editconvert to answer

Okay, so I was confused. We have the 32MHz crystal, but not the 32Khz crystal. Sorry about that confusion.

Definitely Confused ( 2017-05-09 19:36:09 +0100 )editconvert to answer

Well that's much better.

Double check the rotation of the 32MHz as Sigurd suggested. It is an easy mistake to make. After that I would suggest posting your schematic and code to someone for review. Trying to debug a fault starting up the SD can be tedious via the blog.

AmbystomaLabs ( 2017-05-09 19:39:48 +0100 )editconvert to answer

Was the issuse fixed when you added --drv_vector_table_base=0x0 ? This line was not there by default in the example you used?

Sigurd ( 2017-05-12 16:51:56 +0100 )editconvert to answer

It was fixed by added that line. It wasn't there in the project I was using. I had copied over just the IAR project file, but not the debugger file

Definitely Confused ( 2017-05-12 17:11:01 +0100 )editconvert to answer

Great that you found the solution. This is a known and old bug from IARs side, where IAR will jump directly to the application's reset handler when starting debugging, instead of running the softdevice's reset handler. The line is therefore needed to force the debugger to know that the interrupt vectors are located in the SoftDevice. The line is added by default in all the IAR BLE examples in the SDK.

Sigurd ( 2017-05-12 17:38:11 +0100 )editconvert to answer

1 answer

Sort by » oldest newest most voted
ConfusedIndividual gravatar image

answered 2017-05-11 16:31:25 +0100

updated 2017-05-12 17:52:20 +0100

Apparently this is the issue I was having https://devzone.nordicsemi.com/questi... For my future sanity, is it known why IAR does this?

edit flag offensive delete publish link more

Question Tools



Asked: 2017-04-21 18:31:31 +0100

Seen: 355 times

Last updated: april 21 '17