Forums » Software Development »
Instructions to get going with the OMAP PWM
Added by Andrew Bean over 8 years ago
I'm trying to get EPWM1A running with the MityDSP-L138 module and MityDSP-L138 (F) Family Development Kit.
1) Is there a set of instructions or any discussion on using the PWM specifically for the MityDSP-L138? All I need is a square wave where I can adjust the frequency by setting the appropriate PWM parameters. I don't need any interrupts set up for it or any other complicated stuff.
2) I've been trying to follow the code in Peripheral_Init.c at C6747_EHRPWM_Example, as well as the information in the documents OMAP-L138 DSP+ARM Processor Technical Reference Manual and OMAP-L138 C6000 DSP+ARM Processor . However, I'm trying to do the configuration more directly, something like the following:
static int mem_fd;
static void * mem_psc0_regs;
static void * mem_psc1_regs;
...
// This code is executed somewhere before any call to PSC0_enable() and PSC1_enable()
/* open the device */
mem_fd = open("/dev/mem", O_RDWR|O_SYNC);
if (mem_fd < 0) {
printf("Failed to open /dev/mem (%s)\n", strerror(errno));
return -1;
}
...
int PSC0_enable(unsigned int LPSC_num)
{
printf("mapping mem_psc0_regs\r\n\n");
mem_psc0_regs = mmap(0, 0x00000FFF, PROT_WRITE | PROT_READ, MAP_SHARED, mem_fd, 0x01C10000);
if (mem_psc0_regs == NULL)
{
printf("Failed to map mem_psc0_regs (%s)\n", strerror(errno));
close(mem_fd);
return -1;
}
int * MDCTL = (int*)(mem_psc0_regs + 0xA00);
int * PTCMD = (int*)(mem_psc0_regs + 0x120);
int * PTSTAT = (int*)(mem_psc0_regs + 0x128);
int * MDSTAT = (int*)(mem_psc0_regs + 0x800);
MDCTL[LPSC_num] |= 0x03;
PTCMD[0] = 1;
printf("wait for PTSTAT\r\n");
while((PTSTAT[0]&0x1) != 0)
printf(".");
printf("\nwait for MDSTAT\r\n");
while((MDSTAT[LPSC_num]&0x1F) != 0x3)
printf(".");
printf("\ndone waiting\r\n\n");
munmap(mem_psc0_regs,0xFFF);
return 0;
}
int PSC1_enable(unsigned int LPSC_num)
{
// quite similar code
}
Is this even a valid way of attempting this setup?
I'm also trying to do some of this kind of setup from the PRU, as follows:
//EPWM1A
M_MOV32 R0, SYS_BASE
LBBO R1, R0, PINMUX5, 4
AND R1.b0,R1.b0,#0xF0
OR R1.b0,R1.b0,#0x02
SBBO R1, R0, PINMUX5, 4
#define PWM1_BASE 0x01f02000
#define TBCTL 0x00
#define TBSTS 0x02
#define TBCNT 0x08
#define TBPRD 0x0a
#define CMPCTL 0x0e
#define CMPAHR 0x10
#define CMPA 0x12
#define CMPB 0x14
#define AQCTLA 0x16
M_MOV32 R0, PWM1_BASE
MOV R1,0xC030
SBBO R1,R0,TBCTL,2
MOV R1,0x0000
SBBO R1,R0,TBCNT,2
MOV R1,0x000a
SBBO R1,R0,TBPRD,2
MOV R1,0x0001
SBBO R1,R0,CMPA,2
SBBO R1,R0,CMPB,2
MOV R1,0x0003
SBBO R1,R0,AQCTLA,2
Is this a method that can work? This does not seem to be working. Am I missing something, or is there something completely different that I should be doing?
3) I see that EPWM1A is connected to signal CAN_CS_N on the L138 development board, which is, of course, connected to the CAN controller on the board. Will driving a square wave onto that chip be a problem, assuming I'm not using the CAN at all?
Replies (1)
RE: Instructions to get going with the OMAP PWM - Added by Jonathan Cormier over 8 years ago
Andrew Bean wrote:
I'm trying to get EPWM1A running with the MityDSP-L138 module and MityDSP-L138 (F) Family Development Kit.
1) Is there a set of instructions or any discussion on using the PWM specifically for the MityDSP-L138? All I need is a square wave where I can adjust the frequency by setting the appropriate PWM parameters. I don't need any interrupts set up for it or any other complicated stuff.
I'm not sure if anyone here has used the pwm's on the L138. Looking at the l138 kernel to see if they had a pwm driver I was surprised to find TI didn't include one for the l138. Comparing the L138 TRM and 335x TRM the pwm sections appear to be almost copied from one to the other so there is a chance that the 335x pwm kernel driver will work for the L138. At the very least you could use it as reference.
Note that the L138 mitydsp-linux-v3.7 branch does have the pwm-tiehrpwm.c driver. Though I'm not sure if anyone is using the 3.7 branch or how well its supported.
However it should be possible to setup and control the pwm from userspace like you've been trying. I'm not sure which path will prove easiest.
2) I've been trying to follow the code in
Peripheral_Init.cat C6747_EHRPWM_Example, as well as the information in the documents OMAP-L138 DSP+ARM Processor Technical Reference Manual and OMAP-L138 C6000 DSP+ARM Processor . However, I'm trying to do the configuration more directly, something like the following:
[...]
Is this even a valid way of attempting this setup?
I would think so, you are essentially doing the steps a pwm driver would do if it existed.
Note: You can use the devmem utility from linux to read and write registers. This may help in debugging the pwm register settings.
root@mityomapl138:~# devmem
BusyBox v1.21.1 (2013-10-14 14:39:43 EDT) multi-call binary.
Usage: devmem ADDRESS [WIDTH [VALUE]]
Read/write from physical address
ADDRESS Address to act upon
WIDTH Width (8/16/...)
VALUE Data to be written
root@mityomapl138:~# devmem 0x01f02000
0x00020083
I'm also trying to do some of this kind of setup from the PRU, as follows:
[...]
Is this a method that can work? This does not seem to be working. Am I missing something, or is there something completely different that I should be doing?
You should be able to configure the pwm registers from the DSP, ARM, or the PRU. I'm not sure of all the steps you need. The example you linked mentions the following steps.
Configuring the PLL
Powering up the necessary peripherals (PSC0 and PSC1)
Configuring the necessary pins (PINMUX)
Enabling up interrupts (IER)
Initializing EHRPWM0
3) I see that EPWM1A is connected to signal CAN_CS_N on the L138 development board, which is, of course, connected to the CAN controller on the board. Will driving a square wave onto that chip be a problem, assuming I'm not using the CAN at all?
Since this line is connected to the spi chip select of the can chip, the chip shouldn't interfere with that line. It may enable the can chip to talk on the CAN_SOMI/CAN_SIMO pins whenever CAN_CS_N goes low. But this shouldn't hurt anything if you aren't using that spi bus for anything. Worst case you could remove the chip u900 from the devkit.
