Inconsistent Register Behavior (Inaccessible PWM structure Registers)

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Inconsistent Register Behavior (Inaccessible PWM structure Registers)

Jump to solution
1,198 Views
stevejanisch
Contributor IV

I am porting workable code developed in Processor Expert to MQX 4.0.  I am using the TWR-MCF5441X Tower.

I started by reproducing PE macros setReg16, getReg16, clrReg16Bits, and setReg8Bits.

I then replace the register definitions in PE with the board pointer (pX).

What I am seeing is that certain registers are accessible this way, and others are not.

For example, the GPIO structure IS accessible and I can toggle an LED on the board with this code:

  clrReg16Bits( pX->GPIO.PCR_G, 0x03U ) ;   // G0: 0x03 : 10 Pull-Enabled, 01 Pull-Up

  setReg8Bits(  pX->GPIO.PODR_G,  0x01U ) ; // Set Port G.0 high, all others low

  setReg8Bits(  pX->GPIO.PDDR_G,  0x01U ) ; // Configure G.0 as output          


The PWM structure, on the other hand IS NOT accessible.  When I read the registers back all values return 0xFFFF.

  setReg16( pX->PWM.PWM_SM0INIT,  0xFF00U ) ; // Initial - Start/Minimum/Reset Count

  setReg16( pX->PWM.PWM_SM0VAL0,  0x0000U ) ; // Value 0 - middle point of PWM period

  setReg16( pX->PWM.PWM_SM0VAL1,  0x0100U ) ; // Value 1 - End/Maximum/Modulo/Counter Reload


Since I am trying to build a driver for the mcPWM module, this is a problem.

Can anyone shed light on why I can access certain registers but not others this way?

Is it feasible there are some code enables deep within the BSP that are preventing these registers from being read or written (I would suspect the access problem is two-way since the registers all appear to be 0xFFFF on boot while from the PE example they are zero).

Full Example Code

// Macros from processor expert.................................................

#define setReg16(RegName, val)          (RegName = (uint_16)(val))

#define getReg16(RegName)               (RegName)

#define clrReg16Bits(RegName, ClrMask)  (RegName &= (uint_16)(~(uint_16)(ClrMask)))

#define setReg8Bits(RegName, SetMask)   (RegName |= (uint_8)(SetMask))


// Board pointer and test variable..............................................

VMCF5441_STRUCT_PTR  pX   = _PSP_GET_IPSBAR() ;

uint_16              nVal = 0 ;


void test( void )

{

  // Turn on LED1===============================================================

  // This is just an easily verifiable initial test to ensure understanding of code

  // Direct Access through pointer to GPIO Register... WORKS

  // (Verified by seeing LED illuminate and reading back register values)

  clrReg16Bits( pX->GPIO.PCR_G, 0x03U ) ;   // G0: 0x03 : 10 Pull-Enabled, 01 Pull-Up

  setReg8Bits(  pX->GPIO.PODR_G,  0x01U ) ; // Set Port G.0 high, all others low

  setReg8Bits(  pX->GPIO.PDDR_G,  0x01U ) ; // Configure G.0 as output          

  nVal = pX->GPIO.PCR_G ;

  nVal = pX->GPIO.PODR_G ;

  nVal = pX->GPIO.PDDR_G ;

 

  // PWM Configuration==========================================================

  // Direct Access through pointer to PWM Structure... DOES NOT WORK

  // (Reading back register values denotes 0xFFFF in every register)

  setReg16( pX->PWM.PWM_SM0INIT,  0xFF00U ) ; // Initial - Start/Minimum/Reset Count

  setReg16( pX->PWM.PWM_SM0VAL0,  0x0000U ) ; // Value 0 - middle point of PWM period

  setReg16( pX->PWM.PWM_SM0VAL1,  0x0100U ) ; // Value 1 - End/Maximum/Modulo/Counter Reload

  // All reads return 0xFFFF

  nVal = pX->PWM.PWM_SM0INIT ;

  nVal = pX->PWM.PWM_SM0VAL0 ;

  nVal = pX->PWM.PWM_SM0VAL1 ;

}

0 Kudos
1 Solution
732 Views
Martin_
NXP Employee
NXP Employee

Steve,

do you enable clock for mcPWM in PPMHR1[CD34] ? Out of reset this bit is high, means clock for this module is disabled. Try writing it to zero.

View solution in original post

0 Kudos
5 Replies
732 Views
c0170
Senior Contributor III

Hello Steve Janisch,

I wonder why you read 0xFFFF, reset value of those registers is alleged to be 0. If you open register window in CW, can you check values of PWM registers if it's really 0xFFFF after reset? Are you using debug or release target?

What about clock enablement for PWM module ? How do you handle that in MQX? There's _bsp_enable_card function in code file named init_bsp. Clock's enablements are located in gpio_init code file.

I have not MCF 54418 board at my hand right now, therefore those questions before I get one board to test your pointer approach.

Regards,

c0170

732 Views
stevejanisch
Contributor IV

Thanks for your feedback.  I don't think the registers are truly 0xFFFF... I think that something in MQX is blocking IO to the registers (just a hypothesis at this point).

In a non-MQX project, the PWM registers appear normal and can be read and written to (see attached word or pdf file).

In the MQX project, certain registers appear normal and can be read and written to (e.g. GPIO Port G) but the PWM Module registers appear as 0xFFFF and do not appear to be written to (again see attached).

So I don't think the question is about the pointer approach (I have tried more direct methods and get the same outcome -- the GPIO registers can be read and revised; the PWM module registers cannot) or about clock enables.

I am very new to Coldfire, CodeWarrior, and MQX, but it appears to me that since PWM module register IO works in the non-MQX project but not in the MQX project it has something to do with MQX.

I will look a bit closer at the options and code for _bsp_enable_card.  A quick look didn't show anything referring to "PWM", but perhaps the absence of any such reference is in fact a problem... although it is very difficult to reverse engineer that which is missing and undocumented.

0 Kudos
733 Views
Martin_
NXP Employee
NXP Employee

Steve,

do you enable clock for mcPWM in PPMHR1[CD34] ? Out of reset this bit is high, means clock for this module is disabled. Try writing it to zero.

0 Kudos
732 Views
stevejanisch
Contributor IV

Well that is just %#@* brilliant !!

As soon as I clear the PPMHR1[CD34] bit the CodeWarrior register view for the PWM module registers changes from all 0xFFFF to realistic values.  I can read/write the registers and produce the same results as the non-MQX code.

I see the bit was cleared in the PE_low_level_init section of the non-MQX processor expert code.  I had missed it carrying over the code.

Thank you very very much !

0 Kudos
732 Views
c0170
Senior Contributor III

Excellent, as we have proposed both me & Martin, clock enablement was a problem. Always bear in mind to enable clocks for a module you want to use :smileywink:

Regards,

c0170

0 Kudos