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

[RK]

2. Section 11.2 of the softdevice spec - you only have App High and App Low interrupt priorities available for your app, that's 1 and 3 (APP_IRQ_PRIORITY_LOW, APP_IRQ_PRIORITY_HIGH). And don't use '1' and '3', use the defines for compatibility.

3. Why would setting the TIMER1 IRQ priority help with your use of the LPCOMP interrupt? Set the LPCOMP IRQ priority.

[RK]

You made me go test it. If I load the softdevice but leave it unprotected (ffffffff in CLENR0) then initialising the softdevice with sd_softdevice_enable() doesn't change anything in the MPU PERR0 to protect peripherals and I can access anything. If, however, the softdevice is 'protected' when loaded, ie CLENR0 is 0x18000, the SD init does mark a number of the peripherals as region 0, which would mean accessing them from user code would hardfault. I just tested accessing one, it hardfaulted.

However .. PPI isn't one of them, at least not with SD 8.x. Did that change? I remember seeing posts about accessing PPI directly under the SD hardfaulting before, I'll go find one later. That makes me wonder what version of the 110 the OP is using and whether it's 'protected' or not. I think 'stuck' must mean 'in an error handler' and I can't think of another reason accessing PPI would error.