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.

Problems with HET

Other Parts Discussed in Thread: RM48L952, HALCOGEN

Hello!

Why very simple program listed in "NHET getting started" application note spraba0b.pdf does not working?

Breakpoint from HET modules is generated and the only way to continue debug or work is set bit0=0 in HETGCR.

Registers value after stopping program execution (program is stopped at small time after starting N2HET):

HETEXC2 = 0x100

HETPAR = 0x20

I write PFR = 0x700 for lr=128, GCR is 0x00070001

If I add six instructions in .het file without changing other files

  BR      { next= L00, cond_addr= L00, event = ZERO}

  BR      { next= L00, cond_addr= L00, event = ZERO}

  BR      { next= L00, cond_addr= L00, event = ZERO}

  BR      { next= L00, cond_addr= L00, event = ZERO}

  BR      { next= L00, cond_addr= L00, event = ZERO}

  BR      { next= L00, cond_addr= L00, event = ZERO}

then program begin to work.

The key problem is that I not use halcogen to clear HETRAM and HETRAM is overwriten only by my het program without clearing before writing. And other (unused!) commands in HETRAM is executed because of bug in RM48L952 chip.

For testing, you may fill HETRAM to 0xFF before loading user program, and het program after loading to HETRAM from that application note will not work.


There is need to have unknown at this moment number of instructions that will not stop N2HET module (no breakpoint bit).

  • Hello Vitaliy,

    I have forwarded your post to one of our HET experts. They should be getting back with you shortly.

  • Hi Vitaliy,

      Can you please confirm what you describe is the silicon behavior or the NHET simulator behavior?

      I guess what you are saying is that once you hit a breakpoint in one of the NHET instructions, it just halts and can not resume operation even if you set the Ignore Suspend bit (bit 17 of the HETGCR) to high. When the NHET hits a breakpoint in one of the NHET instructions, it generates a debug request to the CPU. The CPU will halt and enter debug mode as the result. If you need the NHET to resume operation while the CPU is still in debug mode, you will need to clear the debug status flag (bit 8 of the HETEXC2) register. This will "un-halt" the NHET. Note that once the NHET resumes operation and it will eventually execute the same instruction which has the BRK bit set. This again will halt the NHET and set the debug status flag in the HETEXC2 bit unless you clear the BRK bit in the NHET instruction that has it set.

      I'm not too sure if you intentionally try to use the Breakpt feature of the NHET. Or you just see the NHET hitting a breakpoint by itself. Please let me know. If you enable NHET (bit0=1 in the HETGCR) before the NHET program is loaded to the HET RAM, then the NHET can execute on garbage instructions. These garbage instructions can potentially lead the NHET to assert debug request to the CPU and halt the CPU.

      Another thing I want to ask if how you link the NHET program to your project? I guess you use the NHET IDE to create your NHET program. After you compile the .het code both the .c and .h will be generated. in HalcoGen you will select the checkbox "Enable Advanced Mode" and also provide the path to the .c and .h files as shown below. Please let me know if this is how you link the NHET files to your project before you build the porject.

  • Hello, Charles.

    Look at attached CCS project for RM48USBSTICK. 3005.tsthet.zip

    It is not working. Right after starting N2HET, program is stopped in CCS.

    It begin to work if I change 0xFF to 0x00 in memset call (line 10 in sys_main.c) or if I add six commands "BR      {cond_addr=L00, event = NOCOND}" to the end of .het file.

    BTW, what does N2HET instruction do with DATA, CONTROL and PROGRAM fields = 0?

  • Hello Vitaliy,

      In your het code you need to have a conditional address for the MCMP as shown below. When NHET executes the MCMP it will need to take either the next address or the conditional address depending on the compare result. When the compare result is false it takes the next address which is going back to CNT at the beginning of the next het loop. When the condition is true you need to tell NHET what the conditional address the NHET should execute next. Since it is left out, the conditional address field as I look in the memory browser is actually 2 which means to executes an instruction after MCMP which does not exist. Since you first fill the entire HET RAM with F's, the BRK field at address 0x2 is high. When NHET executes this invalid instruction, it sees a BRK field set and generates a debug request to the CPU and hence halt the CPU. When you add bunch of Branch instructions after MCMP these are valid instructions even though they don't do useful work for your application. After the fix, I can see on the scope that you are generateing a 20MHz PWM with 25% high phase and 75% low phase.

    L00: CNT{next = L01, reg = A, max = 624}

    L01: MCMP{next = L00, cond_addr=L00, reg = A, en_pin_action = ON, hr_lr=HIGH, pin = CC0, action = PULSEHI, order = REG_GE_DATA, data = 0x1D4, hr_data = 0x60}

  • Thank you! As I supposed, programs in your application note is correct, but it is not so.

  • Hi Vitaliy,

      Good catch! The apps note is missing the conditional address field. I will request an update. Thanks.