• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 585 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS570LS0914: Clashing definitions in code generated by HAL and HET-ide using both N2HETs

Burns Fisher
Intellectual 560 points
Part Number: TMS570LS0914
Other Parts Discussed in Thread: HALCOGEN

I want to use the two N2HETs in my TMS570, one for emulating a UART and one for a second I2c bus.  The UART has been working just fine for some time, and now I am adding the I2c separately. In both cases, I am using the TI examples.  I tweaked the UART a tiny bit, but have not yet changed the I2c at all.

I'm essentially the IDE only to generate the code (e.g. HET_EMU_I2C.c and HET_EMU_I2C.h).  Not to do any emulation.  In HAL, I'm specifying the .h and .c files for the UART emulator in NHET Driver Settings for HET1 and similarly for the I2c emulator in HET2.

I have a couple problems for which I am looking for advice.

(a) When the line labels in the HET code are turned into C code, there is nothing added relating (say) to the name of the HET file so that the header files generated by the HET IDE for the two programs have colliding definitions.  For example both HET programs have a label Check_Stat1, and the HET IDE generates labels pHET_CHECK_STAT1_0 for both header files.  I can, of course, go through the HET files and de-duplicate the labels, but somehow the _0 on the end implies to me that the IDE might now how to change the #defines if I know how to tell it correctly.

(b) Similarly, these header files define "HET_v2" to be 1, while std_nhet.h (generated by HAL) defines it to be 0.  The right thing happened with only a single HET program.  However, there are incompatible redefinitions when I'm combining two separate IDE-generated files.

Do you think I am using these tools incorrectly so they are generating header files wrong?  Thanks!

  • 0 in reply to QJ Wang
    Intellectual 560 points

    Dear QJ Wang.

    Thanks, but that is exactly the application note (and its associated code) is where I got the I2c code in the first place.  The actual problem is when I attempt to use two separate HET programs (this one and something very similar to the UART emulator) in the same program.  In this example, only a single HET program is used at once, and it is also in CCS project by itself.  The problem comes when I try to incorporate two separate HET programs into a single CCS project as described in my original question.

    It almost seems that the HET IDE must be able to deal with that situation given the forms of the labels.  Thanks...

  • 0 in reply to Burns Fisher
    Intellectual 560 points

    I may have found the answer to this problem.  See this link.  It sounds like, in order to use two separate N2HET programs, you have to assemble the second one by hand with a special compiler switch.  PLEASE IDE folks...this is silly.  It should be just a property of the project which N2HET (1 or 2) you are developing for, and the IDE should add the switch itself..  

  • 0 in reply to Burns Fisher
    Intellectual 560 points

    And there still appears to be a bug somewhere in the order that std_nhet.h in included by the two het programs, and possibly het.c and het.h themselves.  Note that het.c includes std_nhet.h BEFORE it includes the two hetp-generated header files for two het programs.  std_nhet defines the symbol HET_v2 to be 0 conditionally (if it is not otherwise defined).  But it is the first include, so it does define it to be 0.  Later on,  the generated header files unconditionally define HET_v2 to be 1, which is, under some circumstances, an illegal redefinition that the CCS compiler complains about. 

    I fixed it by defining HET_v2 to be 1 in the "user code" section 1 of std_nhet.h. 

    We will find out if this works later, but it does compile.

  • 0 in reply to Burns Fisher
    TI__Guru**** 197076 points

    Hello,

    You can combine two programs (SCI, I2C) together and execute them in N2HET1 RAM. LS0914 has 2 N2HET modules, so you can place SCI code in N2HET1 RAM and I2C code in N2HET2 RAM. Both N2HET RAM support 160 instructions.

  • 0 in reply to QJ Wang
    Intellectual 560 points

    Hello.  I was going to leave this, but I got an email asking if you had resolved my problem.  No.  Although your suggesting of combining the two programs would work around the problem, the only real fix to the problem that I found was the other response from several years ago which I linked to above.  And as I said, the code generated by HALCoGen even when doing that has a bug.  Is there a better way to report this bug and to suggest a checkmark on the IDE to specify which HET is to be used?  I'm happy to do that, but I wanted to ensure that someone saw this bug before I "closed" this report by marking it resolved.

  • 0 in reply to Burns Fisher
    TI__Guru**** 197076 points

    Hello Burns,

    Since you have solved this issue, I will close this thread. Thanks

    https://e2e.ti.com/support/microcontrollers/hercules/f/312/t/868786

  • 0 in reply to QJ Wang
    Intellectual 560 points

    Dear QJ Wang.  My personal issue is solved, but I would like to emphasize that there is a problem with the code generated by HalCoGen in the case where two N2HET devices are used.  I'd also like to ensure that my strong suggestion that there should be a GUI method to compile for HET2 should be included in the HET IDE.

    Is there a different way that I should report this?

  • 0 in reply to Burns Fisher
    TI__Guru**** 197076 points

    Thanks Burns,

    We don't have plan to update HALCoGen. But we will add this issue and workaround to HALCoGen release note.

    we can switch the order of the header files in het.c:

    #include "het.h"

    #include "NHET_01.h"

    #include "NHET_02.h"

    #include "std_nhet.h"
    #include "sys_vim.h"
    /* USER CODE BEGIN (0) */
    /* USER CODE END */