• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 30 subscribers
  • Views 141 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: nERROR asserted on cold startup/other issues

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

I am developing for an RM46 Launchpad using the latest version of HALCogen, targeting GCC Tools (I'm using the arm-none-eabi-gcc 10.3 release). I am debugging using a Segger J-Link via GDB. For some reason, it appears that while I'm consistently able to run my firmware when loading into Flash via JTAG, the moment I try to unplug the debugger and perform a cold reset (i.e. removing USB cable, re-installing to perform a power cycle), I get one of the following failure modes. For context my firmware performs the following:

- GIO Init (User LEDs A and B are configured in HALCogen to default ON as a sign of life at startup)

- RTI Init

- RTI Enable Compare 0 Event

- RTI Start Counter 0

- SCI Init (I'm using SCI LIN module with RX interrupt enabled)

- CAN Init (I'm using DCAN 1 module with Message Box 1 as a TX message, Box 2 as an RX message with RX interrupt enabled)

Note that all of the above functionality works just fine when I load code into Flash via JTAG (and trigger program run via "continue" statement via GDB and the Segger emulator)

However, if I perform a "cold" reboot by actually removing and reinstalling the USB cable, I get one of the following behaviors:

- Board appears to get to gioInit() --> I conclude this as LEDs A and B come on. However, they do NOT blink even though I have set them up to be toggled by the RTI and SCI RX Notifications (Note this works just fine on a JTAG load and continue cycle). In this case, it appears simply pressing and releasing the PORRST button on the Launchpad PCB causes my code to correctly start up and run otherwise normally.

- Board powers up to a red nERROR LED. No further sign of life. In some cases, this issue persists between reboots (even cold reboots with all power removed/cycled)

I have tried a number of things to chase down possible issues:

- I have verified my build system is actually compiling the C entry point (_c_int00) in ARM mode.

- I have made a few changes to sys_link.ld to ensure all of flash is initialized to a known pattern (i.e. either valid program data or a filler pattern) to facilitate flash ECC auto-calculation. As far as I'm aware this should be the only thing I need to do to ensure all of the flash memory ECC area is correctly initialized to prevent ECC errors escalating to an ESM Group2/3 event.

I'm somewhat tearing my hair out chasing this down at the moment and would appreciate any help on this.

-AG

  • 0
    Prodigy 20 points

    A small update:

    It appears the issue is at least somewhat related to interrupts. I went ahead and wrote a simply LED blink loop using a busy for loop (with ASM NOP's to create a timed delay) and a call to gioToggleBit() on a user LED and it appears with just this code running (and a call to _disable_interrupts_() prior to loop execution) the MCU tends to start up fine. This is obviously still not a full resolution as I do need to be able to enable interrupts.

    I also still see occasional cold resets where I get a red nERROR and nothing else, so maybe there's still some ESM startup bug in effect occasionally...?

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

    Hi Abhi,

    Does the LED blink in an interrupt ISR? When the nERROR is asserted, can you check which flag bit is set in the ESM status register 3 (ESMSR3)?