This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

51822 PWM unstable

Hi guys,

I use the 51822's PWM recently, PWM is made by GPIOTE+PPI+TIMER, and the PWM source code as below(I use TIMER1, GPIOTE[0], PPI_CH[0], PPI_CH[1], period and duty means ticks with 16MHz):

void startPwm1(uint16_t period, uint16_t duty)
{
	NRF_TIMER1->INTENCLR = TIMER_INTENSET_COMPARE0_Enabled << TIMER_INTENSET_COMPARE0_Pos; 
	NVIC_DisableIRQ(TIMER1_IRQn);
	
	NRF_GPIOTE->CONFIG[0] = GPIOTE_CONFIG_MODE_Task << GPIOTE_CONFIG_MODE_Pos |
							GPIOTE_CONFIG_POLARITY_Toggle << GPIOTE_CONFIG_POLARITY_Pos |
							WAVE_PWM << GPIOTE_CONFIG_PSEL_Pos | 
							GPIOTE_CONFIG_OUTINIT_Low << GPIOTE_CONFIG_OUTINIT_Pos;
	
	NRF_PPI->CH[0].EEP = (uint32_t) &NRF_TIMER1->EVENTS_COMPARE[0];
	NRF_PPI->CH[0].TEP = (uint32_t) &NRF_GPIOTE->TASKS_OUT[0];
	
	NRF_PPI->CH[1].EEP = (uint32_t) &NRF_TIMER1->EVENTS_COMPARE[1];
	NRF_PPI->CH[1].TEP = (uint32_t) &NRF_GPIOTE->TASKS_OUT[0];
	NRF_PPI->CHENSET = (PPI_CHENSET_CH0_Enabled << PPI_CHENSET_CH0_Pos) | (PPI_CHEN_CH1_Enabled<< PPI_CHEN_CH1_Pos);
	
	NRF_TIMER1->TASKS_STOP = 1;
	NRF_TIMER1->TASKS_CLEAR = 1;
	
//	NRF_TIMER1->PRESCALER = 0;
	NRF_TIMER1->CC[0] = period;  	
	NRF_TIMER1->CC[1] = period - duty;	
	NRF_TIMER1->SHORTS = TIMER_SHORTS_COMPARE0_CLEAR_Enabled << TIMER_SHORTS_COMPARE0_CLEAR_Pos;
	NRF_TIMER1->INTENCLR = TIMER_INTENSET_COMPARE0_Enabled << TIMER_INTENSET_COMPARE0_Pos; 
	NRF_TIMER1->TASKS_START = 1;
}

When I download the program to the development board, PWM works well(period is 842 ticks, duty is 20 ticks), As shown below:

image description image description

Then power off the development board, and connected other 3.3V power supply to any 51822's GPIO port, then disconnected, power the development board, Now the PWM does not work well, as show below: image description

1 pwm works well, 3 looks like Inverted. It seems like GPIOTE's response is not in time.

So have you encountered this situation?

Parents
  • It's not clear from your code if you are requesting (ie, starting HFCLK_EXT). The nRF will always run from internal HFCLK which is not accurate, you have to request HFCLK EXT.

    If you are using an SD then you request it through an API command, otherwise you can just set up the clock registers and pclk source.

    Also, I assume your comment about powering through gpio port was just a typo, right? You meant just applying vdd from external source.

Reply
  • It's not clear from your code if you are requesting (ie, starting HFCLK_EXT). The nRF will always run from internal HFCLK which is not accurate, you have to request HFCLK EXT.

    If you are using an SD then you request it through an API command, otherwise you can just set up the clock registers and pclk source.

    Also, I assume your comment about powering through gpio port was just a typo, right? You meant just applying vdd from external source.

Children
No Data
Related