This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Interrupt routine does not invoking

Other Parts Discussed in Thread: CONTROLSUITE

Hello all,

I have troubles with invoking isr. Below initialization code and my try of invoking isr (2 ways)

BL_PROGRAM_L1:
    SETC OBJMODE        ;Set OBJMODE for 28x object code

; --- disable WD
    EALLOW              ;Enable EALLOW protected register access
    MOVZ           DP, #WDCR>>6  	;Set data page for WDCR register
    MOV             @WDCR, #0068h  	;Set WDDIS bit in WDCR to disable WD
    EDIS                ;Disable EALLOW protected register access
;--------
    LB	_c_int00	; 

_main:			; 
;--------
	eallow
	DINT;			// Global Disable all Interrupts

;	lcr	INIT_PINS_SUB		;

	movz	DP, #PCLKCR0>>6
	mov	        @PCLKCR0, #0xFFFF

;-------------- init PIE interrupts ---------------------------
	and		IER, #0x0000			;	// Disable CPU interrupts
	and		IFR, #0x0000			;	// Clear all CPU interrupt flags

	movz	DP, #PIECTRL>>6						
	or	        @PIECTRL, #0000000000000001b

	; 
	movl	XAR7, #PIEIER1			; 
	rpt		#(PIEIFR12 - PIEIER1)
	||mov	*XAR7++, #0x0

;-- init isr vectors
	movz	DP, #ADCINT1_VECT>>6					
	mov	        @ADCINT1_VECT,      #BL_ADCINT1_ISR_L
	mov	        @ADCINT1_VECT+1, #BL_ADCINT1_ISR_L>>16
        ; add other isr addresses
        ;
        ;

;-- enable ADC irq
	movz	DP, #PIEIER1>>6
	mov	        @PIEIER1, #0000000000000001b
	; switch other irq's on
	;
	;
	;
	;
	;
;--- 
	or IER, #0000000000000001b

	movz	DP, #PIEACK>>6
	or	        @PIEACK, #0xFFFF

	EINT			

L1:
	nop
	nop
	nop
	cmp		@AL, #1
	bf		L2, NEQ
	INTR INT1
L2:
	nop
	nop
	cmp		@AL, #2
	bf		L3, NEQ
	movz	DP, #PIEIFR1>>6
	or	        @PIEIFR1, #0000000000000001b
L3:
	nop
	nop
	nop
	bf	L1, UNC
In the code above  INTR INT1 works, and isr invoking propely.

but when execute
or	@PIEIFR1, #0000000000000001b
respective flags in PIE and PIEACK is set, but isr is not invoked.

Can isr be invoked this way at all ?

Any help, please.
  • Hi Konstantin,
    Can you check the status of PIEACK before writing to PIEIFR register?
    Please make sure PIEACK is cleared before that.
    Let me know.
    -Bharathi.

  • Hello Bharathi,
    PIEACK =0x0000 from start till i set PIEIFR
    Interesting moment - when i set PIEIFR, resp. bit in PIEACK and PIE is set by MCU and it's impossible in CCS to clear PIEACK by writing 1 to it( via debug).
  • Bharathi,

    Can I send project to you? I tottally missed.

    It's simple, but..

    I've tried it on Experimenter kit board, on my custom board, on Win8 + CCS6, on WinXP + CCS3.3. Result is the same.

    Regards,

    Konstantin

  • Bharathi,
    I've just assembled and tested example from controlSUITE - "ePWM Timer Interrupt". Looks like it's impossible to invoke isr by just setting respective PIEIFR flag bit in code....
    So, there is another question - why I2C module does not call isr if all conditions are met (PIEIFR is set by hardware!)???
  • Hi Konstantin,
    If you are writing to  PIEIFR you should see the interrupt taking place.
    One thing to note is that this bit is automatically cleared when the interrupt is serviced, by hardware.
    Whether is I2C or any other module interrupt - PIEIFR would be set when interrupt is generated and is cleared when interrupt is serviced.
    This is automatically done for peripheral module interrupts.
    In case you are invoking an interrupt by other means (like writing to PIEIFR or INTR) - interrupt should still take place.
    -Bharathi.

  • Konstantin,

    Also, what  are you trying to accomplish by writing to PIEIFR register directly in software?
    May be I can suggest alternate options that might help your usecase.
    But - what you are trying to do is not illegal should generate interrupts.

    -Bharathi

  • Bharathi,
    You are right, setting a bit in PIEIFR has no essential meaning in real soft, but this is a simple way to localize error - in my case isr invoking.
    The problem with isr is that: - when I use single step in CCS (step into, step over, asm step into, asm step over) it does not invoke isr when it should!!!!!, but it invoke isr if i put a breakpoint in that isr and run to it ("resume" key)!! Why it is so strange logic? I used CCS3.3, CCS6.0.1 as described earlier.

    Also I should note, that CCS 6 is very, very slow in single stepping. Much slower then CCS3.3 despite the fact that it is run on a much stronger machine. Also I encounter another problem, which is still not clear. Please have a look at my old post below:

    "I have trouble with ePWM module on 28027 chip. After starting PWM module, I see in debug that period of time-base clock is not constant i.e. time between subsequent changes of time-base counter register is different. I have no idea why it behaves like this? (I developing code entirely in asm, and can see this in infinite loop of NOP's)

    Second issue is with Timer module. Prescale register TIMER0TPR has absolutely nil impact on Timer. CPU-Timer Prescale Counter PSC isn't downcounts and TImer runs at SYSCLCKOUT rate.

    Please, point out what I missing?

    Tnx."
    It is also in single stepping....

    Maybe this two troubles connected somehow?
  • Konstantin,
    Behavior of interrupts si different during single step/halt conditions. What you are observing it expected behavior.
    If you need the interrupt to take place hwne halted you need to enable the interrupt in DBGIER.
    you can refer to http://www.ti.com.cn/cn/lit/ug/spru430e/spru430e.pdf for more details on interrupt behavior during debug.
    - Bharathi

  • But I was not in realtime mode, and as I understand this mode - mcu won't halt in isr in any case, Even if i put a breakpoint in it.
    Ok in any case, thank you very much, I'll check this,
    What about ePWM question? It's very important too.
  • Konstantin,
    Regarding your ePWM timer base question - it's not expected behavior.
    WHat is your observation that lead to believe you that the Timebase period keeps changing?
    How are you observing that? Do you see variation in generated PWM freq?

    " I see in debug that period of time-base clock is not constant i.e. time between subsequent changes of time-base counter register is different."

    Need to give more details...

    -Bharathi.

  • Hello Bharathi
    Period is not constant means next. I set all registers in ePWM module, start it and than enter loop with nop's. Everything works ok, but in that loop, between changes of time-base counter register (TBCTR) a very different number of nop's executed.
    I know about pipeline, waitstates, branch instruction timing at the end of the loop, but the difference is huge! For instance, in period TBCTR changes from N to N+1 executes 10 nop's, from N+1 to N+2 - 3 nop's, N+2 to N+3 - 25 nop's. etc. This is in single step mode. But when i use scope for inspection, - period and duty looks correct....

    Konstantin
  • Konstantin,

    During debug/single-stepping If you want PWM to behave the same way it does during run time - you can set the FREE bit in TBCTL register.
    This allows the PWM counters to ignore halt/single step condition. By default PWM counter would Stop after the next time-base counter increment or decrement.
    Please try setting FREE bit and let me know your observation,

    - Bharathi.

  • Bharathi,
    No, I do not want free run of PWM module during debug.
    I want to see exact timing of generated waveforms in debug by Count Event feature, or by just counting number of executed nop's.
    Is it possible to do? In single step mode?
    I do need to know exact timing of some parts of my code too.
    This was my question.

    Looks like I have problems in JTAG connection/setup. Coz mistery don't leave my code.
    For instnce, now I read 5 bytes from external empty EEPROM from the same address.
    One time i read 5 byte, next time i read 4 bytes and mcu don't generate irq for the last one, then agan read 5 bytes and code runs ok, then i read 2 bytes and code traps in breakpoint where it shouldn't and then enters proper breakpoints... Code enters isr when PIEACK is set (but i have OR @PIEACK #000..010..00 instruction to clear it).... No other interrupts enabled, no other tasks which can influence on execution logic or registers. All this i see in debug.

    Between this attempts I reset mcu in debugger. And after 5 or 6 cycles of reset-run I see message like -... check JTAG connection or choose more reliable clock...

    And sometimes when board halted at breakpoint 2-5 min, I get this message "C28xx: Error: (Error -1135 @ 0x3F2060) The debug probe reported an error. Confirm debug probe configuration and connections, reset the debug probe, and retry the operation. (Emulation package 5.1.636.0)
    C28xx: Unable to determine target status after 20 attempts"

    Can you please help me with that.
    I use XDS100 (TMS320C2000 experimenter kit with F28027 MCU) and custom board made on kit schematic.

    Konstantin
  • Hi Konstantin,

    Single stepping the code and PWM time base are different things.
    First check the correct ness of the PWM waveform generation independently.
    For Profiling your code there are several ways listed below -
    http://processors.wiki.ti.com/index.php/Profiling_on_C28x_Targets
    What interface are you using to read the EEPROM data?
    Are you receiving the data correctly?

    -Bharathi

  • Hi Bharathi,

    Q: Cycle counts for 'step-by-step' and 'run to line' do not match? - was the explanation. But even if each nop in single step mode goes through pipeline alone, there should be approximately equal nop instructions in TBCLK tick, but it doesn't.
    Ok. Now it's clear that i can't use single stepping.

    You mean independently of EEPROM read? Yes, it's independent projects.
    I use I2C interface.
    Yes, now it works. I read correct data and isr executes properly. It's definetly a problem in JTAG setup. Coz I didn't modify code.
    Can you please suggest something.

    Konstantin
  • Konstantin,
    Good to know your EEPROM issue is resolved.
    For the JTAG issues - not sure what exactly your problem could be
    http://processors.wiki.ti.com/index.php/Debug_Handbook_for_CCS#Debug_configurations
    There are some general tips in the link above.
    -Bharathi.