How to specify pinmux configuration for EHRPWM0 in motor_control example for IDK AM437x?

I will ask the ISDK team to help.

Hello guys,
Thanks for answers.
Lower nibbles of those addresses are not "0x3" and "0x6".
I generated my pinmux file and copied the content into am43xx_idkevm_pinmux_data.c located in starterware folder (there is no other pinmux file located outside the starterware corresponding the motor_control example?). I used the Set_2 of eHRPWM0 (which corresponds P23 and T22 pins) - I based on other PWM pins with the options, such as: pull-up, pull-down etc.
The resulting configuration is:
static pinmuxPerCfg_t gPwmss0PinCfg[] =
{

{
// My eHRPWM 0A -> P23
PIN_SPI0_SCLK, (uint16_t)PINMUX_SS_PWMSS_EHRPWM0, \
( \
PIN_MODE(3) | \
((PIN_DS_VALUE_OVERRIDE_EN | PIN_DS_OP_DIS | PIN_DS_PULL_UP_EN) & \
(~PIN_PULL_UD_DIS & ~PIN_PULL_UP_EN & ~PIN_RX_ACTIVE & ~PIN_DS_OP_VAL_1 & ~PIN_DS_PULL_UD_EN & ~PIN_WAKE_UP_EN))
) \
},
{
// My eHRPWM 0B -> T22
PIN_SPI0_D0, (uint16_t)PINMUX_SS_PWMSS_EHRPWM0, \
( \
PIN_MODE(3) | \
((PIN_DS_VALUE_OVERRIDE_EN | PIN_DS_OP_DIS | PIN_DS_PULL_UP_EN) & \
(~PIN_PULL_UD_DIS & ~PIN_PULL_UP_EN & ~PIN_RX_ACTIVE & ~PIN_DS_OP_VAL_1 & ~PIN_DS_PULL_UD_EN & ~PIN_WAKE_UP_EN))
) \
},
{PINMUX_INVALID_PIN}
};
I 'commented' the configuration of ehrpwm0_tripzone_input (P24) to avoid conflict as it belongs to the other PWM Set. The rest of the file seems correct.
Finally, the module was initialized by the {CHIPDB_MOD_ID_PWMSS, 0, 0} structure - the module works as previously, but there is a high state at the A output all the time :/ Could you please suggest what should I do next? I don't know if the changes I made were used because I see no link between Board_pinMuxConfig function and the am43xx_idkevm_pinmux_data.c file located in starterware folder.
Thanks!
JJ

Hi,

Assuming that earlier mentioned first register nibbles now read 0x3, if so, making the other 0x6 might help to root cause. And may be make PWM0 A & B generate a known output to verify that it is indeed the PWM signal.

Regards
afzal

Hello,
None of the above mentioned registers carries those nibbles: there is 0x7 in both. I set them to the desired values 0x3 and 0x6 and nothing changed in the outputs 0A and 0B. I am afraid the pinmux changes were not incorporated - is the am43xx_idkevm_pinmux_data.c file located in ti\sysbios_ind_sdk_2.1.1.2\sdk\starterware\board\am43xx appropriate for the motor_control example located in ti\sysbios_ind_sdk_2.1.1.2\sdk\examples ? I see no other pinmux file in sdk but even temporal deletion of am43xx_idkevm_pinmux_data.c resulted in no build errors which is pretty strange for me.
Thanks!
JJ

Hi,

Once you make the changes in the pinmux file, you need to rebuild the board project so that the changes are reflected in the ISDK examples.

One more thing from the latest schematics, it looks like the EHRPWM0B is not connected to PIN_SPI0_D0, but to CAM1_VSYNC(AC23) . You may need to change this also.

Regards,
Prajith

Hi,

It would be better to follow Prajith's advice regarding pinmux tool/ pinmux API usage, anyway the reasoning for my earlier comments as below (in case it too helps you):

Pinmux for each pin is decided by mux value set for that particular pin in pad conf register of control module. Invoking Starterware pinmux API's should finally be setting those registers. The default for most of the pins (afaik) would be for GPIO functionality, which would be the value 0x7. Control module base address is 0x44e10000 (see L4 wakeup memory map, TRM ch.2). Within control module, offset for each pin conf registers can be found in TRM section 7.3.1. Each pin conf register is named, afaik, by it's Mode 0 functionality. Before starterware pin config API is invoked, pad conf register would have the default value and after it, it would be value decided by starteware API arguments.

Take for eg. eHRPWM3A pin used in existing motor control example, pin used is CAM0_DATA4, configuring it in mode 6 would route eHRPWM3A to that pin. And the register offset as can be seen from TRM is 0xA18. If you check the value of register @0x44e10A18 after reset, it would be 0x7 (GPIO functionality) and after the invocation of "Board_pinMuxConfig()" in motor control example, it would change to 0x6, implies mode 6 for that pin, which in turn means eHRPWM3A functionality at SoC pin.

For eHRPWM0A & eHRPWM0B, pins used per schematics are SPI0_SCLK (offset 0x44e10950) in mode 3 & CAM1_VSYNC (offset 0x44e109D8) in mode 6.

Regards
afzal

Hi,

Thank you both for your answers - it helped me a lot to understand the basis of pinmux control.

Unfortunately, the instance 0 of PWM module doesn't work in my case :(

I followed the above instructions: pasted the code into am43xx_idkevm_pinmux_data.c and rebuilt the 'board' project. In one of my tasks, before any PWM init function, the Board_pinMuxConfig is called with the line {CHIPDB_MOD_ID_PWMSS, 0, 0}. The content of lower nibble at 0x44E10950 (for eHRPWM0A) is still equal to 0x7, what indicates that the pinmux config wasn't successful. It doesn't change in any pinmux mode selected for that pin....

Maybe other pinmux file in 'board' project is 'accidentally' related to my project? I see no relation in project properties in Dependencies option. Can you suggest me how to check the crucial pinmux file dependencies? The PWMSS module seems powered and clocked properly so the reason shouldn't be related to the initialization code itself... An important thing is that the pin remains in high state all the time - at the beginning it seemed that at least a part of PWM was initialized, as for GPIO (pinmux mode 0x7) this high state without any GPIO configuration looks pretty strange.

BTW. Indeed, in IDK scheme, the eHRPWM0B is related to CAM1_VSYNC pin (AC23), however in pinmux tool that location is marked as 'conflict' when eHRPWM0A assigned to SPI0_SCLK (P23) - anyway I checked it too just to be sure - the effect is the same....

P.S.: My PWM initialization code is (there shouldn't be any errors as I based on generic motor_control code):

PowerPWM();
epwmAqActionCfg_t gCfg;
gCfg.zeroAction = EPWM_AQ_ACTION_DONOTHING;
gCfg.cmpADownAction = EPWM_AQ_ACTION_LOW;
gCfg.cmpAUpAction = EPWM_AQ_ACTION_HIGH;
gCfg.cmpBDownAction = EPWM_AQ_ACTION_DONOTHING;
gCfg.cmpBUpAction = EPWM_AQ_ACTION_DONOTHING;
gCfg.prdAction = EPWM_AQ_ACTION_DONOTHING;

/* Init Timer-Base Control Register Configure the clock frequency */
EPWMTbTimebaseClkCfg(SOC_PWMSS0_REG, SOC_EPWM_MODULE_FREQ/CLOCK_DIV_VAL ,SOC_EPWM_MODULE_FREQ);

/* Configure the period of the output waveform */
EPWMTbPwmFreqCfg(SOC_PWMSS0_REG, SOC_EPWM_MODULE_FREQ/CLOCK_DIV_VAL*1000000, Tm, EPWM_TB_COUNTER_DIR_UP_DOWN,EPWM_SHADOW_REG_CTRL_DISABLE);

/* Disable syncin for PWM3 */
EPWMTbSyncDisable(SOC_PWMSS0_REG);

/* Enable syncout  */
EPWMTbSetSyncOutMode(SOC_PWMSS0_REG, EPWM_TB_SYNC_OUT_EVT_CNT_EQ_ZERO);

/* Configure the emulation behaviour */
EPWMTbSetEmulationMode(SOC_PWMSS0_REG, EPWM_TB_EMU_MODE_FREE_RUN);

// // Init Compare Control Register for EPWM1-EPWM3
/* Load Compare A value */
EPWMCounterComparatorCfg(SOC_PWMSS0_REG, EPWM_CC_CMP_A, (Tm/4), EPWM_SHADOW_REG_CTRL_ENABLE, EPWM_CC_CMP_LOAD_MODE_CNT_EQ_ZERO, 1);

/* Configure Action qualifier */
EPWMAqActionOnOutputCfg(SOC_PWMSS0_REG, EPWM_OUTPUT_CH_A, &gCfg);

/* Dead band sub-module Mode Selection */
EPWMDeadbandBypass(SOC_PWMSS0_REG);

/* Disable Chopper sub-module */
EPWMChopperEnable(SOC_PWMSS0_REG, 0);

/* Disable trip events */
EPWMTzTripEventDisable(SOC_PWMSS0_REG, EPWM_TZ_EVENT_ONE_SHOT, 0);
EPWMTzTripEventDisable(SOC_PWMSS0_REG, EPWM_TZ_EVENT_CYCLE_BY_CYCLE, 0);

/* Generate interrupt every 1st occurrence of the event */
EPWMEtIntrCfg(SOC_PWMSS0_REG, EPWM_ET_INTR_EVT_CNT_EQ_PRD, EPWM_ET_INTR_PERIOD_FIRST_EVT);

/* Generate event when CTR = 0 */
/* Clear any Interrupt event */
EPWMEtIntrClear(SOC_PWMSS0_REG);

/* Enable interrupt */
EPWMEtIntrEnable(SOC_PWMSS0_REG);

/* Disable High resolution capability */
EPWMHighResolutionDisable(SOC_PWMSS0_REG);

EPWMClockEnable(SOC_PWMSS0_REG);

Thank you!

JJ

Hi,

Did not see anything wrong in PWM config, though have seen "EPWMClockEnable()" extra as compared to FOC PWM, not expecting it to make a difference.

First we would have to determine who the culprit is - whether PWM or pinmux,

1. Perhaps adapt your code to use PWM3 (since PWM3 is known to work in motor control example) & see if it works (can check at DRV8313 pin for eHRPWM3A).
2. Earlier when you have tried manually updating the pin conf registers for eHRPWM0 as mentioned by me, if it was done was done before pinmux API invocation, do it after & check.

Regards
afzal

Hello Afzal,

I wrote the same code as presented above for eHRPWM3 (the structure {CHIPDB_MOD_ID_PWMSS, 3, 0} for pinmux config was preserved). The voltage measured at the pin 27 (IN1) of DRV8313 is the logic high, similarly to eHRPWM0. The advantage is we know that it takes place for all...

The module might be damaged or there is something wrong with the overall pinmux config process, am I right? I used to have some problems with definitions of GPIO input when declaring the user button interrupt, and that's why I'm so suspicious of this tool.

Is there any way to import the am43xx_idkevm_pinmux_data.c file into my project to be absolutely sure about its usage? Or maybe there might be different reasons for my case?

Thank you!

JJ

Hi,

i don't expect the module to be damaged (99.99%). Assuming you are using oscilloscope to observe waveform. Can you try with motor control example as is & see how the signal looks like., will try to check the same tomorrow without any motor connected at my end too. Have a feeling as though PWM signal is okay, it might be due to CMPA value being set to very low in interrupt handling making it always high (due to the way CMPA is updated in interrupt handler when no current).

Seems PWM0A is okay based on the above, PWM0B pinmux has to be made right, will defer it to Prajith for the pinmux tool/pinmux API usage. Note that PWM3B is not handled as PWM signal in FOC code, but as GPIO.

Regards
afzal

Hi,

Okay, checked PWM3A signal without connecting motors, it almost always high (> 80% duty cycle). With motor connected and not running, signal almost like a square wave (~50% duty cycle)

Regards
afzal

Hi,

I downloaded the motor_control example without any motor connected and eHRPWM3A worked with duty cycle close to 90%, as you wrote. Then in my code I set much higher values in all of the compare registers. The result is that eHRPWM3A measured at pin 27 of DRV8313 works perfect but still there is no response of eHRPWM0A measured at pin 24 of J16 header. There is a high logic value all the time, no matter what value was set in compare register. Both eHRPWM0A and eHRPWM3A were set in the same way, according to the code presented before. As I don't need a B channel at that moment, I declared only eHRPWM0A for P23 pin in am43xx_idkevm_pinmux_data.c file 

Regards,

JJ

Hi,

Can you please provide the register values @0x44e10A18 & 0x44E10950 (after invocation of Board_pinMuxConfig) in the above case (i know that one of those you have provided earlier, but wanted to know it with your latest changes too)

Regards
afzal

Hi Afzal,

Following your instructions, I wrote the following code: 

HWREG(0x44e10A18) |= (uint32_t) 0x7; //Set all mode bits
HWREG(0x44e10A18) &= (uint32_t) (~0x1); //Disable lowest mode bit -> 110 = 0x6

HWREG(0x44E10950) |= (uint32_t) 0x7; //Set all mode bits
HWREG(0x44E10950) &= (uint32_t) (~0x4); //Disable third mode bit -> 011 = 0x3

and now I have my PWM signal at eHRPWM0A :)

I suppose we have just turned on the proper pin mode - as the controle module base address is 0x44E10000 and the offset for PIN_SPI0_SCLK is 0x0950, you asked to set the pin mode manually to the value 0x3, am I right?

I suppose this step should be done by the Board_pinMuxConfig, but it was not. I see there is no direct path to starterware/board/am43xx directory in Include section of the project, but there must be other link to those files as there are no build errors... I have tried using the function PINMUXModuleConfig but without success. Maybe something blocks the Board_pinMuxConfig action?

Regards,

JJ

Hi,

Yes, setting SPIO0_CLK (0x44e10950) to mode 3 so as to have eHRPWM0A functionality was what i wanted, it should have been achieved by using pinmux config API, but that has not happened.

Glad to hear that you are able to get PWM0A signal out of the SoC.

Note that 0x44e10a18 is actually PWM3A, it is 0x44E109D8 to be set to mode 6 for PWM0B. i asked PWM3A pad conf value as you said PWM3A was working and just to verify & avoid confusion.

Handing over the baton to Prajith to do pinmux tool/API dance :)

Regards
afzal

Hi,
Ok - everything is clear now, thank you very much for your help.
I will try some pinmux fun when waiting for Prajith suggestions ;)
Regards,
JJ

Hello,
Sorry for delay in replying.
I have copied the obtained library to the location you specified and it works.
Thank you for your help.
JJ