d.mann

Enable timer conflict w/ ISR BF532

Discussion created by d.mann on Jun 11, 2012
Latest reply on Jun 14, 2012 by jobo23

I have an non-VDK application which requires two ISRs:

(1) SPORT 0 RX DMA ISR (Autobuffer mode) @ FS Sample Rate

(2) SPI ISR

Both of which are REENTRANT and at default priority levels (ivg9 and ivg10 respectively).

 

I am also using TIMER1 Pin in one-shot (PWM) mode to trigger an event to an master processor. My timer settings are:

*pTIMER1_CONFIG = (PWM_OUT | PULSE_HI);

 

System Clock Rate = FS*256

 

If the triggering event occurs, I load the timer width in the SPORT ISR with a value that is always less than 256.

*pTIMER1_WIDTH = 128; (for example)

ssync();

After the width is loaded, in the following SPORT ISR, I enable the timer:

*pTIMER_ENABLE |= TIMEN1;

ssync();

 

I should also state that there is no chance the the timer can be reloaded while it is still running. This is due to the timer width always being much less than the triggering event period.

 

I have found that the simple act of enabling this timer resource creates havoc with my spi communications. Like there is conflicting scheduling resources from the timer being active. There is no ISR or interrupts associated with the timer. My registers show only SPORT RX and SPI for interrupts.

*pSIC_IMASK = 0x00002200;

 

Is there some underlying resource that is used when the timer is enabled, or when it expires that create a conflict with other resources? Is there any consideration necessary for the fact that the default priority of the timer resource is lower (if used as an interrupt)?

 

Here are some other relevant regs:

SIC_IAR0 = 0x10000000;

SIC_IAR1 = 0x33322221;

SIC_IAR2 = 0x66655444;

SIC_ISR  = 0x00000200; or 0x000022000 (depending on what ISRs have been serviced)

SIC_IWR = 0xFFFFFFFF;

Outcomes