• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 29 subscribers
  • Views 238 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.

LAUNCHXL2-RM46: HALCogen + GCC project setup

Abhi Ghosh
Prodigy 20 points
Part Number: LAUNCHXL2-RM46
Other Parts Discussed in Thread: SEGGER, HALCOGEN

Hi all,

I am attempting to set up a simple hello world project on an RM46 Launchpad (RM46L852PGE) target. I am debugging the board via its 20-pin TI JTAG header, using a Segger J-Link and GDB. 

I am able to get to a running Application and am attempting to use the RTI Compare 0 interrupt to implement a basic 1 kHz timebase. However, the moment I enable interrupts it appears the processor jumps to an undefEntry handler which is presently the Halcogen-generated infinite loop. I set a breakpoint on the rtiCompare0Interrupt vector, as well as the rtiNotification that is supposed to be called by that IRQ vector after the RTI Interrupt is acknowledged.

It appears somewhere in the jump from rtiCompare0Interrupt() to rtiNotification() that the CPU never makes it there and instead winds up in the undefEntry... Any ideas on what could be causing this?

  • 0
    Prodigy 20 points

    Quick follow-up: I managed to fix the issue. It appears HALCogen doesn't generate an ARM mode pragma for the interrupt handlers installed to VIM RAM. As a result, code compiled in Thumb mode (aka most of my project) includes these handlers, causing an Undef Exception upon IRQ entry. I was able to fix the issue by prepending an __attribute__((target("arm"))) to my RTI IRQ in rti.c.

    On a final note, I have a humble suggestion to the HALCogen Team as a somewhat longtime user of the RM and TMS series of TI Cortex-R products: Please test your code generation outputs for not just the TI tools but also GCC. This issue should've been caught in really basic V&V and should never make its way into a customer's project. I also noticed that even the latest HALCogen (which is what I'm running) *still* has the code generation bug I reported on TI's forums 6 years ago relating to the C entry point _c_int00 not having an ARM mode pragma, leading to a dead-on-arrival CPU when performing a cold reset. This simply isn't acceptable.

  • 0 in reply to Abhi Ghosh
    TI__Guru**** 186226 points

    Thanks Abhl. I will add your solution to HalcoGen release note. We don't have a plan to update the HALCoGen for IAR/GCC/GHS tools at this moment.