Skip to content
Snippets Groups Projects
Select Git revision
  • ef6e62ac04e5775e3c89f283d6e93ed5215d6110
  • master default
2 results

embedded

  • Clone with SSH
  • Clone with HTTPS
  • Name Last commit Last update
    ..
    atsams70-bldc
    README.md

    Programming the BLDC Driver

    Background

    Here I'm using the chip I set up for my Networking project, it's an ATSAMS70 with four 'ports' for message passing, and a bells-and-whistles header that I'm thinking will be useful for doing-other-stuff (i.e. this motor controller is one of such things).

    The board is documented here and code for the switch (as well as useful bits for some peripheral setup is here).

    The plan

    • do PWM Setup
    • do motor turning around at low level, on some set frequency / duty
    • do UART interface for Frequency / Duty
    • do MODS UART

    PWM Setup

    OK, I'm going to start by turning on the PWM peripherals I'll use to control my switches. A few initial spec's:

    Channels

    • 3 channels, 6 outputs: one hi / one low - per phase

    Base Frequency

    • In selecting a base frequency for the PWM, a real engineer would look at the time constant of their motor. The coils of a motor are basically big inductors, so when voltage is switched 'hi' to them, it takes some time for the current in the coils to rise. The 'time constant' of a system is a pretty broad way to say on what-timescale-does-stuff-happen. So, in a small motor with relativley low inductance, we'll have a small time constant (say, of a few us[microseconds]). I'm not exactly sure what the units are like here, but I think this is like the time it takes for current to rise to 66% of what a full-out 'on' current level would be. This has something to do with impulse response.
    • For the motors I'm using (smallish), I know (purely imperical) that a base frequency on the order of 10kHz is what I'm aiming at - a period of 100us. In microcontroller time, this is fairly slow! Additionally, this frequency generates an audible buzz (we hear the coils 'banging' on the mechanical system of the motor at this frequency) so being able to push this frequency outside of the audible range is awesome.

    Deatime Insertion

    • Because the circuit is setup with a high and low side mosfet, and the fets don't switch instantaneously, if we were to switch the high off and low on instantaneously, there would be a brief moment when the high and low switches were both on, allowing current to 'shoot through' from VCC to GND, and this is bad. To get around this we do something called 'deadtime insertion' - just putting a few us of off-time on both channels, between switching. There is a register for this, and additionally the DRV8302 does this automatically - so I maybe don't need to worry about it off the bat, but if it's straightforward I'll do that.

    ADC and PWM Synchronization

    • I'm reading current off of 'current shunts' that are 'below' my low-side mosfet.
    • Current only flows through these shunts when the low-side mosfets are on! Otherwise, they are open to nothing, nothing flows, no measurement etc.
    • I have to coordinate my ADC sampling with the center of the on-cycle of the low-side PWM. There are ways to do this with the peripherals, but it's cross-linking peripherals in the event system, so this will be a challenge.
    • I don't need to do current control yet so I'm going to save this struggle for later on!

    I'm tempted to use the ASF modules for this..

    However, I didn't! I got through this massive set of registers (holy shit there are PWM options for days) by carefully reading... guess.. the datasheet! Sweet deliverance of knowledge from the Si gods... In the ATSAMS70 Datasheet particularely, bouncing between 47.6.6 (PWM initialization sequence) and 47.6 (Functional Description) and 47.7 (Register Descriptions). I was able to work through it. I have one pwm line operational, now I'm looking at how to get the low-side of that signal operating as well... Here's a trace from my logic analyzer, digital and analog signals of the high side of this channel. I have the frequency correct - a good start.

    pwm-one-channel

    So my second channel is not enabled because I've made an error in labelling pins! Here's the group prior to my noticing the error:

    pwm-one-channel

    and corrected

    pwm-one-channel

    OK, so I'm going to have to keep track of this carefully, and I'm probably going to have to jumper wires between boards, rather than using these stacking headers. Welp. This is why we do incremental development.

    With this confusion out of the way, here's a complete channel - high and low sides of my gates:

    pwm-one-channel

    And a detail on the deadtime insertion:

    pwm-one-channel

    Here's the code I'm running:

    
    void setuppwm(void){
    	PMC->PMC_PCER1 = 1 << 28; // turn on peripheral clock for PWM 1
    	// these are pins for channels 1, 2, 3 in lo / hi pairs
    	PIOD->PIO_PDR = PIO_PER_P2 | PIO_PER_P3 | PIO_PER_P4 | PIO_PER_P5 | PIO_PER_P6 | PIO_PER_P7; // disable PIO
    	PIOD->PIO_ABCDSR[0] = PIO_PER_P2 | PIO_PER_P3 | PIO_PER_P4 | PIO_PER_P5 | PIO_PER_P6 | PIO_PER_P7; // enable peripheral B
    	//PIOD->PIO_ABCDSR[1] // already these are 0s, we want that [01] is peripheral B
    	
    	// PREA Clock is Peripheral Clock / 64
    	// PREA Clock supplies Clock A, Clock A is PREA / 24
    	// Clock B is off
    	PWM1->PWM_CLK = PWM_CLK_PREA(2) | PWM_CLK_DIVA(7) | PWM_CLK_DIVB_CLKB_POFF;
    	// Channel 0 uses CLCKA, uses Center Aligned, has dead time, is waveform aligned (with others?)
    	PWM1->PWM_CH_NUM[1].PWM_CMR  = PWM_CMR_CPRE_CLKA | PWM_CMR_CES | PWM_CMR_DTE | PWM_CMR_CALG;
    	// Channel 0 uses this period
    	// (2 * 2^PREA * DIVA * CPRD) / f_peripheralClock
    	// so for 10kHz target frequency, we want 1 / 10000, 
    	// have (2 * 64 * 12 * x )/ 150000000
    	// ~ spreadsheets are your friends ~
    	PWM1->PWM_CH_NUM[1].PWM_CPRD = PWM_CPRD_CPRD(255);
    	// set duty cycle, initially, to low
    	// this is between 0 and CPRD, so it looks like shooting for a big CPRD is (y)
    	PWM1->PWM_CH_NUM[1].PWM_CDTY = PWM_CDTY_CDTY(1);
    	// configure deadtime generator, between 0 and CPRD - CDTY
    	PWM1->PWM_CH_NUM[1].PWM_DT = PWM_DT_DTH(2) | PWM_DT_DTL(2);
    	// configure update mode
    	// mode 1 is 'manual write of double buffer registers and automatic update of synchronous channels'
    	// other modes are for manual write / manual  update and DMA mode
    	// also add sync. channels - spec that 0, 1, 2 are ~ on the same wavelength, man ~
    	PWM1->PWM_SCM = PWM_SCM_UPDM_MODE1 | PWM_SCM_SYNC0;
    	
    	// now, boot it up
    	PWM1->PWM_ENA = PWM_ENA_CHID1; // just channel 0 for now
    	
    	// understand: compare? clock? update? duty cycle register? period register?
    }
    
    int main (void)
    {
    	board_init();
    	sysclk_init();
    	wdt_disable(WDT);
    	
    	setuppwm();
    	
    	PMC->PMC_PCER0 = 1 << ID_PIOA;
    	
    	PIOA->PIO_PER |= PIO_PER_P27;
    	PIOA->PIO_OER = PIO_PER_P27;
    	
    	startupflash();
    	
    	while(1){
    		// to update, must use duty update register, not just 'duty' 
    		PWM1->PWM_CH_NUM[1].PWM_CDTYUPD = PWM_CDTY_CDTY(20);
    		delay_ms(100);
    		PWM1->PWM_CH_NUM[1].PWM_CDTYUPD = PWM_CDTY_CDTY(155);
    		delay_ms(50);
    	}
    }

    Now I'll set up three channels for my three half-bridges, write a function to do sinusoid open-loop commutation, and maybe even test that out on a motor! I'll also write a function to change the global duty cycle.

    Here's my shorthand pin-mapping

    pwm-one-channel

    I want to push these values to my phases:

    pwm-one-channel

    Where the '0' point will be 1/2 of a full-on pwm phase (so, with my CPRD of 255, 127 - this is where the half bridge is switched hi half of the time and low the other half), -1 is a pwm duty of 0 (where the half bridge is switched low 100% of the time) and 1 is a value of 255 (where the half bridge is switched high 100% of the time).

    Here we go, a sinusoidal PWM:

    pwm-one-channel

    I think I'm ready to check all of my other motor controller IO's - like, do I need to assert, also, an enable pin? I forget. Then I'll plug it in, and flip the switch, ho-ha! Yep - I just have on extra PIO to add, an Enable Pin. Set this up.

    UART

    OK, I'm going to bring up the UART. I have a block of code for this from my networks project that I'll try bringing in.

    This works, largely. I'm bringin the UART Baudrate way down to 9600... I'm getting characters returning on the line, now I need to setup the interrupt system to handle transmitted characters, and echo them.

    Figuring out how the heck the interrupts work was a PITA. Kind of interesting, though - the Interrupt System is technically an ARM-Cortex domain thing, and so Atmel's datasheets barely touch on it... they say things like 'configure the interrupt controller before doing this' - but NOWHERE does it explain how to do that. Heck.

    Here's my brief:

    • There are a set # of interrupts, they are enumerated in the software framework, and naming is pretty straightforward, for example, UART1 Interrupt Number is UART1_IRQn ...
    • There are a few globally defined NVIC setup functions, which take these IRQ Numbers as arguments. Their naming convention is also pretty straightforward
    • NVIC_DisableIRQ(IRQn) // disables!
    • NVIC_SetPriority(IRQn, uint8_t priority) // 0-255 priority, 0 being the highest
    • NVIC_EnableIRQ(IRQn) // enables!
    • When one of these interrupts fires, it directs to a pre-defined Handler. For example, the UART1 handler is UART1_Handler(){// code for handler} - Atmel Studio's autocomplete makes this work excellently.
    • Critically, most interrupts require that you clear some register, usually just by reading it.
    • in the UART example, I clear the event by reading the UART data in register. This will vary between peripherals, and it's not documented anywhere, so poke around!

    Here's my Setup Code (runs in main())

    	NVIC_DisableIRQ(UART1_IRQn);
    	NVIC_ClearPendingIRQ(UART1_IRQn);
    	NVIC_SetPriority(UART1_IRQn, 9);
    	NVIC_EnableIRQ(UART1_IRQn);

    of course, I'm also setting up the UART peripheral... to see that, you can check out the code in this repo!

    Here's the interrupt routine - properly, I would quickly push this data into a ringbuffer (to be implemented) and exit the routine - ISR's (interrupt service routines) should be very small, lest you get a barrage of them... buffering is bueno. Here, I'm just passing the received character back - this is an echo test, a good way to make sure everything is working as it should. It is, hurray!

    void UART1_Handler(){
    	if(UART1->UART_SR & UART_SR_RXRDY){
    		uint8_t data = UART1->UART_RHR; // read the incoming data
    		while(!(UART1->UART_SR & UART_SR_TXRDY)); // hang-10 to make sure the UART is ready to send
    		UART1->UART_THR = data;
    	} else {
    		//
    	}
    }

    Note - the handler does not distinguish between an RXReady event and the other interrupts - a TXReady, for example, so in this routine I would have to also check which has fired and act accordintly...

    Some ARM Documentation is here - navigate to Cortex-M7 Documentation, the latest revision, and look for NVIC.

    From here, I brought up the hardware - a satisfying adventure. Go here for that.

    Then I worked (briefly) on implementing a control interface for this using mods. That should be here in week 12.