Freescale MAC7100 doze mode

I'm not able to manage Freescale MAC7100 doze mode keeping alive the
RTI module.

To start RTI I use the following code:

  PIT.TLVAL[0].B.TSV = System_Clock/2*1000*bt;
  PIT.INTEN.B.RTIE = 1;                      // Pit interrupt enable
  PIT.CTRL.B.MDIS = 0;                       // Module Enable
  PIT.EN.B.PEN0 = 1;
  INTC.IMRL.B.IMR22 = 0;

To handle the interrupt I use the following code:

  PIT.EN.B.PEN0 = 0;
  PIT.EN.B.PEN0 = 1;
  PIT.FLG.B.RTIF = 1; // clear the flag

OK, the RTI interrupt handler (interrupt 22) is periodically called.

To enter the doze mode I use the following code:

  MCM.MWCR.R=0x80;
  CRG.CLKSEL.B.PLLSEL = 0; // 8 MHz
  CRG.SDMCTL.B.DOZE = 1;   // DOZE MODE

I also have:

CRG.PITCTRL.DOZE = 0
CRG.CLKSEL.RTIDOZE = 0

When I enter doze mode the PIT interrupt handler stops to be called.

Any help?

Thanks,
Marco O.

Sorry, the OP has probably long solved this problem, but I'd
like to add a comment anyway. This is not the DOZE mode problem, but:

>  PIT.FLG.B.RTIF = 1; // clear the flag

This doesn't work in the general case. Bitfield headers tempt the
user to think that it would, but in reality it's different - you 
want to clear a single flag, but in order to write a single bit in 
a register, the compiler generates code to read the register, 
logically OR the contents and write the results back. This is the 
right behaviour for a control register, of course.

However for a flag register this means that every bit currently
set, will be written with a "1" - and the flag bits happen to be 
clear-on-write!. In other words, "PIT.FLG.B.RTIF = 1;" will clear 
every single bit in PIT.FLG which is currently set.

If the RTI is your only timer your code will still work, but
if two timers are used this method will have nasty side effects.

A better method would be to write "PIT.FLG.R = 0x01;" which clears
just RTIF (which happens to be bit 0). This is faster too since
it just needs a single write, instead of a read-modify-write operation.


Cheers



Stefan







		
This message was sent using the comp.arch.embedded web interface on
www.EmbeddedRelated.com