TMS570LS3137: Trying to activate IRQ from N2HET1 for Level 0 Interrupt

What I was expecting is that with all those HET1 registers set this way, it should get into my ISR (breakpoint set), but never did.

Also, the TMS570LS3137 device datasheet spns162c is talking about N2HET1 level 0 (channel 10) and level 1 (channel 24) interrupts (Table 6-31), while its TRM spnu499c HETPRY register is talking about N2HET1 priority level 1 and priority level 2 ... is there a problem?

Thanks.

Hello Sunil,

Thank you for pointing out that, my bad. For some reasons I've swapped the line position of ISR names #10 and #11 within my 96-entries table that was used to determine the REQENASET0 register contents. Now it is much simpler since I've disabled other unused ISR and the REQENASET0=0x00100405, with which ISR #10 for N2HET1 Level 0 is now enabled.

However, as soon as I turn ON the N2HET1 machine by setting bit 0 of the HET1GCR.TO register to 1, even without any rising edge for the WCAP instructions, N2HET1 interrupts are both declared for L01 and L02 (N2HET1 flag register). What is strange is that my code got lost after this point, even if I clear manually the TO bit and read the HET1FLG to clear the interrupts. My ISR #10 code is like below, and the breakpoint was set on the "dummy=HET1FLG" line, but the debugger stopped at "__irq __arm void IRQHandler_N2Het1Level0(void)", and stayed there, cannot continue any further with the "RUN" command, and never reached the breakpoint at dummy=:

__irq __arm void IRQHandler_N2Het1Level0(void)
{
    dummy = HET1FLG;
}

Below is my original N2HET code (program RAM contains the corresponding code generated by the TI NHET IDE):

L00 CNT     { next=L01, angle_count=OFF, reg=A, max=0x01FFFFFF }
L01 WCAP    { next=L02, reg=A, pin=CC16, irq=ON, event=RISE, hr_lr=HIGH, data=0 }
L02 WCAP    { next=L00, reg=A, pin=CC20, irq=ON, event=RISE, hr_lr=HIGH, data=0 }

Could you please leave this thread open so that I can provide more details on the problem later?

Also can you please confirm the question of my second post, on whether level 0=high priority and level 1=low priority?

Thank you!

Chuck,

I can certainly leave the post open until all your questions are answered. The high/low priority is determined by the channel number on the VIM to which the interrupt request is tied to. The interrupt manager (VIM) prioritizes channels with a lower channel number (0 is highest, 127 is lowest). That is why HET interrupt 0 is a higher priority interrupt since it is tied to VIM channel 10, and HET interrupt 1 is a lower priority interrupt as it is tied to VIM channel 24.

As for the interrupts generated as soon as the WCAP is executed the first time, are the channels CC16 and CC20 driven low when you enable the HET?

Regards,
Sunil

Sunil,

Only pin CC20 is connected to the function generator now, N2HET1 interrupt for CC16 is disabled, only CC20/L02 is enabled. The generator outputs a square wave of 100 Hz and L02 should issue IRQ on every rising edge. I see the HET1FLG = 0x00000004 for line L02, which is correct, but my debugger just breaks somewhere in my code (right after setting HET1GR.TO=1 and cannot continue execution (i.e. debugger RUN command has no effect and the Disassembly remains on the same instruction that is not a loop command).

The N2HET1 was configured to run at 100 MHz (10 ns per instruction, lr=4 for 40 ns and number of time slots=4).

Any idea where should I look for?

Regards.

Sunil,

I'm using an early version of the TI HDK and the MCU marking is TMX570LS3137BZWTQQ1YFB - 25ASX4WGI.

Note that it is not TMS570 but TMX570. Wondering whether this could make a difference (flaws exist in that MCU???) ...

Thanks.

Well Sunil,

Now I've removed IRQ generation from my N2HET1 timer machine (both L01 and L02 with irq=OFF), HET1INTENAS=0, so the H2HET should be completely standalone (HET1FLG always=0). However, as soon as I turn on the N2HET1 machine, the code get lost and could stop at any instruction, and remains there!

Maybe not related to my N2HET code, but the configuration of the N2HET timer machine.

Can you please suggest where to look?

Thanks.

Chuck,

The N2HET processing engine is fairly independent of the main CPU. Is it possible for you to upload your code project so I can replicate your observation? What does your main() routine look like?

Regards,
Sunil

Hi Sunil,

Of course and thank you! Please find attached my code with the project and the code for the N2HET initialization, which correspond to the configuration of my latest post.

In the McuDevices.cpp, the entry point that is called from the main() is void tagMcuPeripherals::InitAllDevices(). The freeze (get lost) occurs right after calling N2HET1.Init() (where the last instruction is turning the N2HET1 timer machine ON), and before the execution of VIM.Enable1(). Note that no N2HET1 interrupt is generated with this configuration.

Thank you!

3404.FreqSampling.zip

Hi Chuck,

The CCMR4 self-test does not run and also does not finish if the CPU has entered a debug state prior to running this test, hence the code execution being lost. Can you make sure that you only set a debug breakpoint after the CCMR4 self-test is completed?

Regards,
Sunil

Hi Sunil,

Thank you for your suggestion. It may explain the behavior. However, whether I've a breakpoint set or not, it gets lost anyway if the HET machine is being turned ON, right way.

I've continued trying thing on my end, and I've inserted a 5ms delay before turning on the HET machine (TO bit) after the memcpy() to the HET RAM, guess what, it works and didn't get lost anymore.

    // enable output buffers of the pin structure, protect program field
    // ignore suspend = 0, N2HET is master (single N2HET configuration), turn OFF N2HET

    HET1GCR = 0x01050000;

    // set the pressures sampling program to the N2HET RAM

    memcpy((void *)&HET1P_RAM_BASE, HET_INIT0_PST, sizeof(HET_INIT0_PST));
    CLOCK.WaitDelayMs(5);

    // turn ON N2HET: sampling starts immediately

    HET1GCR = 0x01050001;

Do you have an explanation on this? I must have missed this delay  somewhere in the TRM. BUT GOD, I don't have this delay in other projects and all of them was working just fine!!!

Weird!

Thanks.

Sunil,

Sorry I celebrated my finding too quick.

The same problem came back after a couple of reset cycles. Now even with a delay of 5ms, still no luck.

I commented out the call to CCMR4F.RunTests(), AND set HET1INTENAS = 0: still no luck.

The only way that I can come out from the code lost problem is: after the memcpy() to store to HETP RAM, breakpoint at the wait delay of 5ms, during which I manually go to the HETP RAM location and clear all code in L00, L01 and L02.

This means that if I turn ON the N2HET without a program it in, no code lost problem. Otherwise, even if I don't generate the IRQ from the N2HET to eliminate the interaction with the CPU, still not working.

That must be something ...

Sunil,

Once the N2HET machine is enabled and "running", and after stopping the execution, even after issuing multiple "run" commands, the debugger remains on the very same instruction all the time, in this case, it is at the entry point of the IRQ handler for N2HET Level 0, as follow (never reached the breakpoint in red):

Can you please let me know what could be the reason and what registers should I look at?

Thanks.

Hi Chuck,

Can you send me an executable file or the entire code project and not just the HALCoGen file for your project? There should be no delay required after copying the program to the HET RAM. Does the code go through system initialization before jumping to the main() routine? Are all the clocks and peripherals initialized?

Regards, Sunil

Sunil,

I've nailed down to a very specific location of the problem, if this still not helping us, I'll forward data that you've requested without problem, and thanks in advance. Also I just want to tell you that the clock and domains should be all good, since my RS232 @57600 bps and my 1 ms system tick interrupt (RTI) are all performing as intended.

With all today's troubleshooting, I've determined that HDK TMX570 H2HET1 pin CC16 (MCU pin A4, or, HDK J11 pin 54) is not working for my purpose. Whenever I use that pin, the software gets lost and always stays at one single instruction, which is always the first instruction of the associate ISR.

Essentially, the below code working 100% fine:

L00 CNT     { next=L01, angle_count=OFF, reg=A, max=0x01FFFFFF }
L01 WCAP    { next=L00, reg=A, pin=CC20, irq=ON, event=RISE, hr_lr=HIGH, data=0 }

But when swapping CC20 by CC16, it gets lost:

L00 CNT     { next=L01, angle_count=OFF, reg=A, max=0x01FFFFFF }
L01 WCAP    { next=L00, reg=A, pin=CC16, irq=ON, event=RISE, hr_lr=HIGH, data=0 }

Any clue?

I'll check tomorrow and will let you know if I find something. This pin in the HDK might be reserved for something else, or I didn't initialize it correctly.

However, if I'm not wrong, this pin have only one single purpose, HET1[16]. See HDK schematics pages 8 and 29.

Thanks.

Good morning Sunil,

Quick question: please let me know if lr=4 instructions, do I have to define all the lines for L00, L01, L02 and L03, or I can leave L03 undefined, as no line will set next=L03?

In my case only 3 lines have been defined and I've noted in the memory that starting at address 0xFF460030, there are all garbage, which could explain the code lost.

Thanks.

Hi Chuck,

You can have only three instructions in the HET progam if you wish. Just make sure that the "next instruction" for L02 is programmed to be L00. This will complete the HET loop. Your HET code pasted above does that already.

I will look into your earlier post and get back to you. The N2HEt1[16] signal does not have any specific connections, just to the connector.

Regards,
Sunil

Hi Sunil,

Thank you for your reply. Just want to let you know that I manage to advance well in my debugging with the HDK, using the N2HET1. However, I have to manually clear the 16-byte space occupied by the 4th instruction in order to have it working properly, as you can see in the below snapshot (again, I've VCLK=100 MHz, hr=1, lr=4, note that starting at the 5th instruction @ 0xff460040, all garbage again - maybe you can show me a master clear bit to clear all 160-instruction memory???). With this fix, even pin NHET1[16] is now working properly and never get lost. Both interrupts from L01 and L02 are being called as intended.

Another observation was that, even with program memory of L01 and L02 jumping back to L00 by using PF=0x00001600 during my testing (so L02 should never be executed), it has been observed that both lines were executed and IRQ generated, with ISR called and validated, counter increased etc., which is NOT normal. And this behavior leads me believe that when lr=4, all 4 instructions are executed before looping back. Hence the question.

I know, nosense! But could it be because my MCU is an TMX570 rather than an TMS570?

Please do let me know if you have something for me.

Thanks again!