• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 29 subscribers
  • Views 903 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

HalCoGen 04.05.00 issues - TMS570LS3137 and TMS570LC4357

Jiri Janacek
Genius 3315 points
Other Parts Discussed in Thread: TMS570LC4357, TMS570LS3137, HALCOGEN

Dear all,

I have identified a few (potential) issues in code generated by HCG 04.05.00 - please check the list below.

Thanks for your comments,

Best regards, Jiri

******************************************************************************
TMS570LC4357
******************************************************************************

-------
HL_std_nhet.h
-------
not in accordance with TMS570LC4357 (BIG endian) TRM SPNU563–May 2014
incorrectly modified (switched) endiannes conditions fo the preprocessor

-------
HL_pinmux.h
-------
#define PINMUX_BALL_R4_SHIFT 8U

HCG  04.04.00
#define PINMUX_BALL_R4_GIOB_3 (uint32)((uint32)0x2U << PINMUX_BALL_R4_SHIFT))

HCG 04.05.00
#define PINMUX_BALL_R4_GIOB_3 (uint32)((uint32)0x3U << PINMUX_BALL_R4_SHIFT))

Based on the datasheet SPNS195A –FEBRUARY 2014–REVISED MAY 2014 I would recommend
#define PINMUX_BALL_R4_GIOB_3 (uint32)((uint32)0x1U << 10))
#define PINMUX_BALL_R4_GIOB_3 (uint32)((uint32)0x4U << PINMUX_BALL_R4_SHIFT))

-------
HL_pinmux.c
-------
pinMuxReg->PINMUX[9] = PINMUX_BALL_R4_
instead of the expected sysmbol
pinMuxReg->PINMUX[9] = PINMUX_BALL_R4_GIOB_3

-------
HL_sys_core.s
-------
lines 529 and 533 (DSB instruction)
a comment character not accepted by GCC compiler - ";" instead of the expected "@"

******************************************************************************
TMS570LS3137
******************************************************************************
-------

reg_esm.h
-------
OK - ESTATUS5EMU not included in TRM SPNU499B

-------
HL_std_nhet.h
-------
not in accordance with TMS570LS3137 (BIG endian) TRM SPNU499B
incorrectly modified (switched) endiannes conditions fo the preprocessor

  • 0
    TI__Guru 65600 points

    Hi Jiri,
    Sorry for the delay on the response. Thank you for reporting these issues.


    I agree that there is a problem in HL_std_nhet.h. I am guessing this is a result of the fix for issue SDOCM00116928 which noted that the IAR toolchain only defines __little_endian_ but sets it to 0 for big endian and 1 for little. It looks like the #if got changed to address this, but the code under it didn't get swapped to match the difference in the test condition. I filed a ticket on this issue - it's number is SDOCM00118073.

    Also agree on the HL_pinmux.h issue with PINMUX_BALL_R4_GIOB_3 - I think someone was thinking bit '3' of the byte but wrote 3U instead of 4.
    Filed a ticket on this: SDOCM00118074

    For the issue in pinmux.c:
    pinMuxReg->PINMUX[9] = PINMUX_BALL_R4_GIOB_3 | PINMUX_BALL_N17_EMIF_nCS_0 | PINMUX_BALL_L17_GIOB_4;
    I just generated the above with 4.05.00, so I'm not able to reproduce the issue as reported. Not sure if there's some other variable in the mix. Maybe we could get the files you used to generate from. (I started with a clean project).

    Re. HL_sys_core.s - agree based on sourceware.org/.../ARM_002dChars.html
    so filed a ticket: SDOCM00118075

    reg_esm.h I believe we already have a ticket on - but thanks for pointing it out. There are a few forum posts on this issue. We determined that it doesn't hurt to write to the register, it's a register that would be there in a 'larger' configuration (with more ESM channels) than are used on the LS3137 device. We agree it needs to be removed, but it's been deemed 'inert'.

    The HL_std_nhet.h is probably an across-the-board mistake not just on these two parts, so I added a note to SDOCM00118073 asking it be checked for all the platforms. If the change was made for the IAR toolchain, then it probably was made across the board.

    Thanks and Best Regards,

    Anthony

    Note: edited to hopefully be easier to read.

  • 0 in reply to Anthony F. Seely
    Genius 3315 points

    Hello Anthony,

    thank a lot for your precise answer!

    You are right with HL_pinmux.c "issue" - I am sorry that was the false alert, a mistake had been on my side. Obviously I had omitted the setting in HalCoGen sub-tab: PINMUX -> Input Pin Muxing -> GIOB[3]: R4.

    Another question regarding your bug tracking system - I remember I could have searched  and opened for the reading some reports which were referenced e.g. by your colleagues in the past. Now I have not been able to search the record if I inserted the ticket ID, e.g. SDOCM00118075.

    Have access rules been changed somehow? HalCoGen code is a part of our project so it would be great to have detailed information how and when pending issues are handled.

    EDIT_00:

    Well, now I have got this error text in a dialog window: 

    >> "ClearQuest login of user: This login is forbidden: CRMMD1881E Invalid Credentials: Either the login name or the password is incorrect." <<


    Is there some proper and official way how your customers can read tickets with limited access, of course?    It seems that I have used some obsolete link to the ClearQuest with invalid inputs...

    Many thanks for your explanation,

    Best regards, Jiri

  • 0 in reply to Jiri Janacek
    TI__Guru 65600 points
    Hi Jiri,
    The CQ database has to be made visible externally for each project. I think this is mainly made public for compilers, etc.
    The HalCoGen team would need to decide to turn the visibility on. If you want to post a separate thread requesting this, I can assign it to the HalCoGen team to look at.
    In any case it's useful for me to at least record the number here - so that we can look up the issue status in the future to see if it was addressed or if it's in the works, etc. Anyone who is a TI employee can look up the status by that number. So even if the CQ database isn't open to look at you can still ask about an issue and refer to it by # and it's a lot easier to get accurate status that way.
    Thanks and Best Regards,Anthony
  • 0 in reply to Anthony F. Seely
    Genius 3315 points

    Dear Anthony,

    public access to ClearQuest related to HalCoGen would be great. I will create a new thread for this topic.

    EDIT_00:

    Created at https://e2e.ti.com/support/microcontrollers/hercules/f/312/t/442440

    Yes, there is an optional way how to get the actual status of the bug report as you mentioned. But that would be convenient for anyone outside TI to have a direct access to all issues listed in one place and controlled in a defined way - tracking system ;-)

    Many thanks for your support,

    Best regards

    Jiri

  • 0 in reply to Jiri Janacek
    Genius 3315 points

    Hello Anthony,

    I have just updated to the HCG version 4.05.01 and I can confirm the fixed issures reported in this thread ;-)

    ******************************************************************************
    TMS570LC4357
    ******************************************************************************
    SDOCM00118074 fixed and confirmed HL_pinmux.h
    SDOCM00118075 fixed and confirmed HL_sys_core.s
    SDOCM00118073 fixed and confirmed HL_std_nhet.h

    ******************************************************************************
    TMS570LS3137
    ******************************************************************************
    SDOCM00118073 std_nhet.h resolved and confirmed

    Thanks and Best regards

    Jiri