Question for NVIC_EnabeIRQ

[Stanley]

Hi,

I'm trying to implement a device including a PWM counter and a high resolution timer working with softdevice stack 110. Per the examples I got from this site, I'm using the TIMER1 in TIMER mode for the high resolution timer, TIMER2 in counter mode with LPCOMP for the PWM counter. The timer and the PWM counter can work well separately without S110 stack, but when I tried to integrate them together, I got some issues. By searching the forum, I can't find some clue for them:

1. If the ble_stack_init is called before the counter initialization, which the PPI channel[0] is used in the counter, the program is stuck at channel[0] initialization. But this issue goes away if PPI is initialized before ble_stack_init is called. Is there any dependency between them?

2. The timer_init is called before ble_stack_init either, and defined as below:

   NRF_TIMER1->MODE = TIMER_MODE_MODE_Timer; // Set the timer in Counter Mode NRF_TIMER1->PRESCALER = 6; //Set prescaler. Higher number gives slower timer. Prescaler = 0 gives 16MHz timer NRF_TIMER1->BITMODE = TIMER_BITMODE_BITMODE_16Bit; //Set counter to 16 bit resolution NRF_TIMER1->CC[0] = TIMER_MS_TO_TICK(1); //Set value for TIMER compare register 0

   // Enable interrupt on Timer, set CC[0] to compare match events NRF_TIMER1->INTENSET = (TIMER_INTENSET_COMPARE0_Enabled << TIMER_INTENSET_COMPARE0_Pos); NVIC_EnableIRQ(TIMER1_IRQn);

But when the ble_stack_init is called, the system reboots. I added some logs, and found that this issue was caused by the call NVIC_EnableIRQ(TIMER1_IRQn). With below line, there is no reboot happened again:

NVIC_SetPriority(TIMER1_IRQn, 1);

Is this setting compulsory if the timer is set as TIMER mode working with S110 stack?

3. The 3rd question is some like above question, I'm trying to use LPCOMP + TIMER2 to implement a PWM counter as the example shown, but when I call NVIC_EnableIRQ(LPCOMP_IRQn), the system reboots at ble_stack_init(). And the call NVIC_SetPriority(TIMER1_IRQn, 1); does't help, even I set the priority as 3. The code is shown as below:

   static void LPCOMP_init(void) { /* Enable interrupt on LPCOMP CROSS event */ NRF_LPCOMP->INTENSET = LPCOMP_INTENSET_CROSS_Msk;

        /* Configure LPCOMP - set input source to AVDD*4/8 */
        NRF_LPCOMP->REFSEL |= (LPCOMP_REFSEL_REFSEL_SupplyFourEighthsPrescaling << LPCOMP_REFSEL_REFSEL_Pos);
        /* Configure LPCOMP - set reference input source to AIN pin 6, i.e. P0.5 */
        NRF_LPCOMP->PSEL |= (COUNTER_PULSE_INPUT << LPCOMP_PSEL_PSEL_Pos);
        
        /* Enable and start the low power comparator */
        NRF_LPCOMP->ENABLE = LPCOMP_ENABLE_ENABLE_Enabled;      
   
        NVIC_SetPriority(CP_TIMER_IRQ, 1);
        NVIC_EnableIRQ(LPCOMP_IRQn);  
   

   }

Could anyone please help me on these issues? Any feedback will be appreciated.

Thanks & Regards, Stanley

[Susheel Nuguru]

Yes RK,

PPI is not protected anymore from SD 8.x, as protecting it does not serve the protection it needs. App can anyways program PPI unrestricted channels to manipulate restricted peripheral behaviour using sd_ppi_*** API. This issue is probably addressed in nRF52 chips. I am guessing that the debugger isn't giving the exact point of where the error occurs probably due to optimisation being too high. I would try again by compiling again with no optimizations and trace again.

Updated 01.06.2015

Softdevice and the peripherals used by it are not protected by default, I think this has changed with SDK8.0. Softdevice does not write to UICR.CLENR0. When initializing the softdevice, it first checks CLENR0, and if it is clean (0XFFFFFFFF) then it will not protect any peripherals. In that case it is upto applications to be careful with what peripherals they are using. RK, you have already made this observation and I can confirm that you were right. If we want the peripherals to be protected, we need to write to CLENR0 register before initializing the softdevice. Something I learned from you today :)

[Stanley]

Thanks RK & Aryan for the help to track PPI issue.

I'm using the SDK 7 (version 7.2.0_cf547b5), and build the project on Ubuntu. The code to initialize PPI interface is as below:

// Configure PPI channel 0 to count up the TIMER counter on every LPCOMP event
NRF_PPI->CH[COUNTER_PPI_CHANNEL].EEP = (uint32_t)&NRF_LPCOMP->EVENTS_CROSS;
NRF_PPI->CH[COUNTER_PPI_CHANNEL].TEP = (uint32_t)&COUNTER_TIMER->TASKS_COUNT;

// Enable PPI channel 0
NRF_PPI->CHEN = (COUNTER_PPI_ENABLED << COUNTER_PPI_POS);

Once this initialization is called, the system hangs up there. I'm saying "hang up" or "is stuck" because I added some logs before and after each line, and I can only see the first log before setting EEP. If the line to set EEP is commented out, the log after line setting TEP can't be printed out.

The initialization process for BLE device is ported from the template in SDK, and so far, it's working if PPI is initialized before BLE device is initialized.

Regards, Stanley

[Susheel Nuguru]

If you are using SDK version 7.x then PPI is a protected peripheral to softdevice. The stuck you mentioned is a hardfault. you can confirm this by setting a breakpoint in the HardFault_handler in your startup files. you have to use SOC API to interact with it after the softdevice is enabled. The code you mentioned here might work before the softdevice is enabled but I still recommend you to use nrf soc API for portability.

[Stanley]

Thanks Aryan for the confirmation, I will move to soc API for this call.

[Susheel Nuguru]

Please accept the answer Stanley, this way we can close this case.