TMS570LS3137 N2HET Pulse generation

huichun xing

Our application needs the MCU to generate a pulse based on customner setting, and such pulse is used on external circuitry to diable certain strobe signal. However the pulse width is ranging from 5 seconds to 30 minuts, accuracy is 0.01%, which is 500us @5 second condition. The generation of next pulse should also be able to be controlled by software. No duty cycle requirement.

I am thinking to use N2HET to generate such pulse, but kind of confused

GCLK=180M

slowest VCLK2=180M/16

HR_CLK (6 bit) /64

LR_CLK (3 bit) /128

7-bit HR Data field

Based on manual 20.2.5.11, it seems we can not get 5 second and 30 minutes by such setting. Any good suggestion about cascading timer to achieve this?

over 13 years ago

0 Anthony F. Seely over 13 years ago

TI__Guru 69070 points

Huichun,

By rough calculations it appears you need > 38 bits of counter for the 30 second mark assuming the N2HET clock is 90MHz.

On the end the constraint of 0.01% at 5 seconds is still 500us or 45,000 clocks for the N2HET at 90MHz.

So I would recommend keeping it simple and using loop resolution for the pulse. The loop resolution could be 128 clocks to leave room for more features to be added to the N2HET code; and with a loop resolution of 128 clocks, you would still be > 300x faster than the requirement.

In that case, you might start with a 64 bit counter which could be as simple as a few add instructions, and then do the comparison with subtract and branch instructions.

I put together something very quickly and did a *tiny* amount of testing in the HET IDE, so it's working enough to express the idea but you should test it thoroughly and especially simulate the counter rollover conditions.

Here is the code. The ARM CPU writes the 64 bit turn on time to BUFONHI, BUFONLO and turn off time to BUFOFFHI, BUFOFFLO.

If you simulate in HET IDE, please note that the HET IDE shows all the pins uninitialized until the first time they are written.

And, you might want to put a breakpoint on "SET_LO" and when you hit this breakpoint you can change the ON/OFF times ahead for the next pulse to simulate a few pulses. I did NOT check the comparison at 64 bits so there could be some typos, (I just simulated with top 32 bits 0's for time reasons). You may want to simulate this by moving the counter ahead in the IDE by overwriting the RAM and probably to run a full test it has to be on silicon since the count is so long.

START   ADD { src1=IMM,src2=ZERO,dest=T,data=0,hr_data=1};

; 64 Bit Counter with loop resolution
CNTRLO ADD { src1=IMM,src2=T,dest=IMM,data=0,hr_data=0};
CNTRHI ADC { src1=IMM,src2=ZERO,dest=IMM,data=0,hr_data=0};

; Compare counter against 64-bit BUFON time
GET_CNTRHI   MOV32 { remote=CNTRHI,type=REMTOREG,reg=R};
GET_CNTRLO   MOV32 { remote=CNTRLO,type=REMTOREG,reg=S};

CMPON_CNTRHI   SUB { src1=REM,src2=R,dest=IMM,remote=BUFONHI,data=0,hr_data=0}
           BR { cond_addr=CMPOFF_CNTRHI,event=NE};
CMPON_CNTRLO   SUB { src1=REM,src2=S,dest=IMM,remote=BUFONLO,data=0,hr_data=0}
           BR { cond_addr=CMPOFF_CNTRHI,event=NE};
SET_HI         SHFT { smode=OR1,cond=UNC,pin=0,data=1FFFFFFh};

CMPOFF_CNTRHI   SUB { src1=REM,src2=R,dest=IMM,remote=BUFOFFHI,data=0,hr_data=0}
           BR { cond_addr=DONE,event=NE};
CMPOFF_CNTRLO   SUB { src1=REM,src2=S,dest=IMM,remote=BUFOFFLO,data=0,hr_data=0}
           BR { cond_addr=DONE,event=NE};
SET_LO         SHFT { smode=OR0,cond=UNC,pin=0,data=0000000h};

DONE   BR {cond_addr=START, event=NOCOND}

BUFONHI   ADD {src1=ZERO,src2=ZERO,dest=NONE,data=0,hr_data=00}
BUFONLO   ADD {src1=ZERO,src2=ZERO,dest=NONE,data=0,hr_data=10}

BUFOFFHI ADD {src1=ZERO,src2=ZERO,dest=NONE,data=0,hr_data=00}
BUFOFFLO ADD {src1=ZERO,src2=ZERO,dest=NONE,data=0,hr_data=20}

Best Regards,

Anthony

0 huichun xing over 13 years ago in reply to Anthony F. Seely

Intellectual 425 points

Anthony,

It seems achievable by using HET loop resolution and comparing with 64 bit counter internal the loop. If I understasnd correctly, the comparing is based on 32 bit instruction, so we need to implement the 64 bit manually by taking care of two 32 bit counters. For 5 second, one 32 bit counter works, for longer time like 30 minutes, dual counter should be applied.

Instead of HET, how about RTI since it seems two are avilable in 64 bit? How much about the latency of RTI, and in the interrupt routine, we can toggle the GPIO. The application needs at least one RTI for system tick and there are other interrupts and DMA. What is the priority setting for such RTI?

Thanks,

huichun

0 Anthony F. Seely over 13 years ago in reply to huichun xing

TI__Guru 69070 points

Hi Huichun,

huichun xing said:

It seems achievable by using HET loop resolution and comparing with 64 bit counter internal the loop. If I understasnd correctly, the comparing is based on 32 bit instruction, so we need to implement the 64 bit manually by taking care of two 32 bit counters. For 5 second, one 32 bit counter works, for longer time like 30 minutes, dual counter should be applied.

That could be an option too. My reasoning behind the 64-bit counter is that it allows the N2HET to still run at it's highest resolution, in case you have other (faster) jobs for the timer to do that could be part of the same program. Anyway the 32-bit counter should be an easy subset to make out of the 64-bit example.

huichun xing said:

Instead of HET, how about RTI since it seems two are avilable in 64 bit? How much about the latency of RTI, and in the interrupt routine, we can toggle the GPIO. The application needs at least one RTI for system tick and there are other interrupts and DMA. What is the priority setting for such RTI?

Also an option, if it meets your accuracy requirements. The interrupt latency for servicing the RTI depends on how high you program it in the VIM and also what other tasks the MCU is doing. For sure you will get more 'jitter' in the waveform if you use the RTI instead of the N2HET.

The RTI has 4 compares, and usually 1 is for the OS tick so the others are available for jobs like this. The way that the RTI is structured, you also don't reset the counter under normal operation (like reset when compare match as other timers might do) . Instead, the compare register has a compare update register where you program the period you want and when the compare triggers it updates the *compare* by adding the period to it, instead of resetting the counter. This way the 4 compares really do operate independently of each other.

Last note, while the RTI has 64-bits of counter, it's really a 32-bit prescaler plus a 32-bit counter. The compares are all off of the 32-bit counter. So in some sense it will be as accurate as using the 32-bit counter in N2HET, except there will be more jitter due to interrupt response time.

The most accurate would be the 64-bit counter on N2HET.

Best Regards,

Anthony

Arm-based microcontrollers

Arm-based microcontrollers forum

TMS570LS3137 N2HET Pulse generation