PWM on i.MX RT 1050 EVKB

[emergentist]

Hello,

I am trying to get some PWM outputs working on the i.MX RT1050 EVKB, using the Arduino-compatible pins.

Specifically, I am trying to route PWM1_A (sub-module 3) to pin GPIO_AD_B0_10 (D5 on the Arduino header) and PWM2_A (sub-module 3) to pin GPIO_AD_B0_09 (D4 on the Arduino Header). The signals are a 5-MHz 50% duty cycle signal and a 1-MHz 50% duty cycle signal, respectively. Simple clocks.

The project (which uses fsl_pwm.c) builds without errors, and I am able to flash the board. Project code (used in MCUXpresso IDE) is attached. I have tried to glean what I can from the reference manual and the SDK examples.

I am using an oscilloscope to measure the signal on the corresponding Arduino pins, but I am getting no signal from D4 or D5. Does anyone have any advice? I have attached my main() code and some config files.

Thanks

[martinhowell1]

The crossbar has to be set up to get the fault inputs in the correct state else they inhibit the PWM output, that cuaght me out at first. You can get round it if you dont want the fault inputs. You can get round that by configuring the fault handling on the PWM channel and in that case you dont need to configure the crossbar, something like this:

pwm_fault_param_t faultParam;

PWM_Type *base = BOARD_PWM_BASEADDR;

// disable the fault inut monitoring
base->SM[kPWM_Module_3].DISMAP[0] = 0;
base->SM[kPWM_Module_3].DISMAP[1] = 0;

faultParam.faultClearingMode = kPWM_Automatic;
faultParam.faultLevel = true;
faultParam.enableCombinationalPath = false;
faultParam.recoverMode = kPWM_RecoverHalfAndFullCycle;

PWM_SetupFaults(BOARD_PWM_BASEADDR, kPWM_Fault_0, &faultParam);
PWM_SetupFaults(BOARD_PWM_BASEADDR, kPWM_Fault_1, &faultParam);
PWM_SetupFaults(BOARD_PWM_BASEADDR, kPWM_Fault_2, &faultParam);
PWM_SetupFaults(BOARD_PWM_BASEADDR, kPWM_Fault_3, &faultParam);

[15219661324]

Hello, I found that just the following two lines of code can also set the PWM output correctly.

PWM_Type *base = BOARD_PWM_BASEADDR;

base->SM[kPWM_Module_3].DISMAP[0] = 0;

So, I wonder if any other code is necessary in the example you gave.

pwm_fault_param_t faultParam;
base->SM[kPWM_Module_3].DISMAP[1] = 0;

faultParam.faultClearingMode = kPWM_Automatic;
faultParam.faultLevel = true;
faultParam.enableCombinationalPath = false;
faultParam.recoverMode = kPWM_RecoverHalfAndFullCycle;

PWM_SetupFaults(BOARD_PWM_BASEADDR, kPWM_Fault_0, &faultParam);
PWM_SetupFaults(BOARD_PWM_BASEADDR, kPWM_Fault_1, &faultParam);
PWM_SetupFaults(BOARD_PWM_BASEADDR, kPWM_Fault_2, &faultParam);
PWM_SetupFaults(BOARD_PWM_BASEADDR, kPWM_Fault_3, &faultParam);

Thanks!

[emergentist]

Martin, thanks for confirming my experience! This MCU is a wonderful but complex little beast.

Thanks for the tip about fault handling, I will explore.

Cheers,

Takis

[emergentist]

After soldering in the 0-Ohm resistors for R279, R280, R281, etc., I have gotten the pwm.c SDK example working. I can see the waveforms on my oscilloscope.

Interestingly, if I comment out the code:

/* Set the PWM Fault inputs to a low value */
XBARA_Init(XBARA1);
XBARA_SetSignalsConnection(XBARA1, kXBARA1_InputLogicHigh, kXBARA1_OutputFlexpwm1Fault0);
XBARA_SetSignalsConnection(XBARA1, kXBARA1_InputLogicHigh, kXBARA1_OutputFlexpwm1Fault1);
XBARA_SetSignalsConnection(XBARA1, kXBARA1_InputLogicHigh, kXBARA1_OutputFlexpwm1234Fault2);
XBARA_SetSignalsConnection(XBARA1, kXBARA1_InputLogicHigh, kXBARA1_OutputFlexpwm1234Fault3);

There are no output signals. I am not sure why this crossbar logic has to be initialized; I would think that, by default, the crossbar logic should not interfere with the routing of PWM signals. Perhaps someone could shed some light on that?

Thanks

[victorjimenez · Accepted solution]

Hello Takis Zourntos, 

Regarding soldering in the 0-Ohm resistors, this information is stated in the readme file of the example. This file comes in all the examples of the SDK and it states all the steps that you need to follow to run successfully the projects.

The intended application of the Inter-Peripheral Crossbar Switch (XBAR) module is to provide a flexible crossbar switch function that allows any input (typically from external GPIO or internal module outputs) to be connected to any output (typically to external GPIO or internal module inputs) under user control. This is used to allow user configuration of data paths between internal modules and between internal modules and GPIO.

With the following lines of the PWM project:

XBARA_SetSignalsConnection(XBARA1, kXBARA1_InputLogicHigh, kXBARA1_OutputFlexpwm1Fault0);
XBARA_SetSignalsConnection(XBARA1, kXBARA1_InputLogicHigh, kXBARA1_OutputFlexpwm1Fault1);
XBARA_SetSignalsConnection(XBARA1, kXBARA1_InputLogicHigh, kXBARA1_OutputFlexpwm1234Fault2);
XBARA_SetSignalsConnection(XBARA1, kXBARA1_InputLogicHigh, kXBARA1_OutputFlexpwm1234Fault3);‍‍‍‍‍‍‍‍

You are setting the PWM channels to a positive logical level, this way when the trigger condition of the PWM occurs the channel will go to a High State. If you comment these lines then when the trigger condition of the PWM ocurrs nothing will happen, the channel will stay on the same logical level.

Regards,

Victor.

[emergentist]

Hi Victor,

Thanks for your input. Yes, I found the readme file somewhat by accident! :smileyhappy: It was a bit tucked away under the docs folder of the project in MCUXpresso IDE.

Also, thanks for illuminating me regarding the Crossbar switch. When you say "any input" can be connected to "any output" via the crossbar switch, I have a little difficulty understanding. The MCU pads are multiplexed, so I thought that only certain GPIOs (and certain PWM outputs), can go to a given pad. Are you saying that XBARA allows me to connect any internal signal to any pad?

Thanks,

Takis

[emergentist]

OK, I now realize that the Arduino header pins on the board, are actually not all connected to the chip pads. I have to solder in some 0-Ohm resistors. This would explain why the PWM Demo from the SDK doesn't work "out of the box". However, the pads I am considering here are GPIO_AD_B0_09 and GPIO_AD_B0_10, and these appear to be connected to the pads of the RT1052 MCU. I am now checking to see if they happen to be connected to anything else.