Using both N2HET modules

Alan,

I would create two separate HET IDE projects maybe even in their own folders.

Then in HalCoGen, each HET shouls have it's own tab.

In each tab you can select which program is loaded into each NHET.

So you can select the output files (C and H from the het assembler) for HET1 and HET2 separately.

The only hangup I think is going to be in the assembler output.  The hetp assembler takes a -nx option where x = 1,2,...9 and is the # of the HET module for which the program is generated.  I'm playing with it and it's not giving the result I expect so will need a little more time to research this.

There isn't an option that I can find in HET IDE to select the het module # by the way,  but I did add the -hc32 and -n2 options to the command line:

And it looks like it got passed to the assembler:

But the outputs still appear to be for HET0.  So need to find out where the disconnect is for you.

Worst case you might have to hand-edit one of the C and H outputs to give it different names for the

data than the other HET output files.

Best Regards,

-Anthony

edit:  fixed the links to the two screen captures which were broken.

Hi,
Additional question:
what is the difference between

(void)memcpy((void*)hetRAM1, (void*)HET_INIT0_PST, sizeof(HET_INIT0_PST));

and

memcpy((void *) &e_HETPROGRAM0_UN, HET_INIT0_PST, sizeof (HET_INIT0_PST));

Which one is prefered?

My understanding is: it's a union?
The first memcopy is done in HL_het.c. But e_HETPROGRAM1_UN and e_HETPROGRAM0_UN remain unresolved in linker.

Best Regards

So, both e_HETPROGRAM0_UN and HET_INIT0_PST have type delcarations in your '<hetprogram>.h' output file assuming you assemble '<hetprogram>.het' for HET 0. If you change the HET # then the '0' in these names will change to that new number..

Only HET_INIT0_PST is also defined in '<hetprogram>.c' as a constant array containing the machine code for the HET program.

This is intended to be loaded into flash because it's a constant array, and it's also intended to be copied to the HET RAM at runtime.

On the other hand, if you look at e_HETPROGRAM0_UN this is declared as a type HET_PROGRAM0_UN which is a union of just program, control, and data record and an unused 32-bit field ("HET_MEMORY" type) and then a structure containing specific structures for each of the instructions, that turn into a way to access the bit fields of the HET program.)

Both of these views are useful for writing the other parts of your driver code (not the memcopy) because by exposing the fields of each opcode it is easy to set the data value of a particular instruction to a particular value, all using the names defined in the header file; which are based on the labels you set in your code. This is important because you avoid hard-coding addresses of HET memory locations in your HET driver code; which would be fragile.... if you added an opcode and all the others shifted down, you can still use the e_HETPROGRAM0_UN to access the same field by name, but if you hardcoded the field's address then the new instruction would break your code.

Anyway since e_HETPROGRAM0_UN is something that is used by the driver to modify the HET code while it's running on the HET, it pretty much needs to be pointed at the HET RAM. Which is what hetRAM1 is.

Now in your question about the memcpy() you could use hetRAM1 without any issue; memcpy() doesn't need to know how to access the fields of the various HET instructions that make up your program.

But, you probably still want to define e_HETPROGRAM0_UN as pointing to the same HET RAM, because your driver code will invariably want to access fields of HET instructions.

You can either handle this by adding a line of code somewhere to set the value, or you can set the value in the linker command file by defining it as a symbol there.

The latter way (through linker) will look like this:

/* USER CODE BEGIN (8) */
e_HETPROGRAM2_UN = 0xff460000;
e_HETPROGRAM3_UN = 0xff460000;
e_HETPROGRAM4_UN = 0xff460000;
e_HETPROGRAM5_UN = 0xff440000;
e_HETPROGRAM6_UN = 0xff440000;
e_HETPROGRAM7_UN = 0xff440000;
/* USER CODE END */

Where the above lines are added to the linker command file.

I took this above from the TI design www.ti.com/.../TIDM-HAHSCPTO example and from it's 'workspace_ccsv61\hss_app\HL_sys_link.cmd' file.

The above shows actually 3 different HET programs that might be loaded (one at a time) into HET0 and 3 more loaded one at a time into HET1, depending on the 'mode' of operation. So you can change modes by loading a different HET program w. an extra 'memcpy' and restarting the HET. Anyway obviously you could just put one line:

e_HETPROGRAM0_UN = 0xff460000;

and be good.

Hi,
thanks a lot for your reply.

/* USER CODE BEGIN (8) */
e_HETPROGRAM0_UN = 0xff460000;
e_HETPROGRAM1_UN = 0xff440000;
/* USER CODE END */

in file TICore/source/HL_sys_link.cmd solved this problem.
Without this change, I was able to compile and to access with a pointer cast:
((volatile HETPROGRAM1_UN*)(void*)hetRAM2)->Program1_ST.DEBUG__1.br.branch_condition = 7U;
I would prefer HALCOgen to auto locate the variables e_HETPROGRAM1_UN and e_HETPROGRAM0_UN by default when they are used rather than doing it with USER CODE. Are predefined const or #define available for accessing the event? (E.g.: C, NC, EQ, NE, NZ, RISE, FALL, ZERO, GE)
Best Regards


PS
using Code Composer Studio Version: 6.1.3.00033,
patched to Code Composer Studio Version: 6.2.0.201604131600 Build id: N201604131600
with C:\ti\Hercules\HALCoGen\v04.06.00\HALCOGEN.exe
and c:\ti\Hercules\bin\hetp.exe NHET Assembler Release 1.7
for TMP 570 4357

Hi Achim,

Achim Olaf Zacher said:

I would prefer HALCOgen to auto locate the variables e_HETPROGRAM1_UN and e_HETPROGRAM0_UN by default when they are used rather than doing it with USER CODE. Are predefined const or #define available for accessing the event? (E.g.: C, NC, EQ, NE, NZ, RISE, FALL, ZERO, GE)

Yes but you might not always want e_HETPROGRAM1_UN to be loaded into HET1.   For example it may be 'personality #2' that is loaded into HET[0] during a certain mode of operation.   Not clear to me that there's a very clean solution here.

I haven't seen any #defines or ENUMs that encode the C, NC, EQ, etc cases.    Typically this is a weakness in the HalCoGen header files, the registers are defined but bit-fields within the register and the values that go into those bit fields are not defined in the headers.   A bit unfortunate but it's that way across most of the headers.

EDIT:  I should add that with the HET instruction set all of the bit fields are not necessarily contiguous.  So beware of this when trying to create your own enums or #defines.

-Anthony