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.

RM57 HDK Unplug - Plug power cable && nError/red LED

Other Parts Discussed in Thread: HALCOGEN, RM57L843

Hi there,

After I program the board and test it without the debugger (unplugging the power cable and plugging it again), the nError LED is always ON. And the program doesn't run 100% correctly.

What could be causing the red LED to turn on?? What can I look for in the ESM routines? 

I am using Halcogen to configure and generate files for Serial, RTI,  EMAC and EEPROM, and I am also using the LwIP and the F021 libraries.

Any help would be appreciated.

Best regards,

Julio Aguilar

  • Julio,

    When the board is in this state, then you can plug in the debugger and launch a target configuration file (without downloading your software and resetting the board) so that you connect to the target after it's running and in the error state.

    Then you can examine the ESM status registers to determine what error occurred.
  • Hi Anthony,

    Thanks for your help.

    SIDE NOTE: I forgot to mention that "sometimes" the nError LED also turns on while debugging!

    I will try to do what you suggest. I didn't know you could do that without resetting the board!

    Best regards,
    Julio Aguilar
  • Hi Julio,

    There is also an errata on this device which mentions that sometimes on the very first time you connect a debugger after a power on reset, you get a false core compare module error.  EDIT: Errata is DEVICE#56

  • Hi Anthony,

    I could connect to the target while it was running without resetting it.

    The thing is that I don't know how to interpret the ESM registers. Well, for starters the ESM2 (critical severity) regsiters are always 0, so I interpret that as good xD

    I have attached 3 pictures where you can see the ESM1 registers in three different states:

    (Well I tried to attache the zip file, but it was taking too long, so I wrote (bellow) what the value of the registers were in those three cases)

    1. Starting the target through the debugger. Everything is OK. No red LED.

        Registers with a value different than 0: ErrPinStat (0x0000 0001), LtCnt & LtCntPre (both 0x0000 3FFF), ShdwStat2 (0x0000 0008) and Stat4 (0x0000 8000)

    2. Powering off the device, powering on again: Program somewhat runs but not exactly as it should. Red LED is ON.

        Registers with a value different than 0: Stat1 (0x8000 0000), Stat2 (0x0000 0004), IntOffsHgh (0x0000 0023), LtCntPre (0x0000 3FFF), ShdwStat2 (0x0000 000C), Stat4 (0x0000 8000)

    3. Target was started with the debugger. Everything was OK. No red LED. Then I stopped the debugger and let the program run. After a while, the program froze and the red LED turned on.

         Registers that are different than 0:  LtCntPre (0x0000 3FFF),  ShdwStat2 (0x0000 0008).

         The program stopped in the file HL_sys_intvecs.asm at:

    prefetchEntry
                b prefetchEntry

    Could you tell me what is going on and how can I fix the problem? Where could I read about it? I have the "Safety manual for RM57" and the "RM57 Technical Reference Manual" but they don't tell me what the errors mean! Or I am missing it.

    Best regards,

    Julio Aguilar

  • Julio,

    For the ESM register descriptions see SPNU563 Chapter 16

    Note that ESMSR2 is cleared by a warm reset, but it's shadow register ESMSSR2 is not. That may provide some clue.

    ESMSR2 and ESMSSR2 (your 'ShdwStat2' because the CCS XMLs don't match TRM, are referring to ESM Group2.

    The table that lists the error conditions for each bit in these registers however is in the datasheet for the RM57L843.
    That is SPNS215C and the ESM channel assignments are listed in Table 6-45.

    If you see 0x04 and 0x0C in ESMSR2 and ESMSSR2 then these are indicative:
    - the 0x04 of a CCM-R5 CPU Compare error, which is probably the errata that we talked about.
    - the 0x08 (part of 0x0C) is an ECC erorr in flash.

    The second one probably corresponds with the prefetch abort.

    You can find the address that caused the abort by looking at the coprocessor registers, there are registers that capture the address where there was an instruction fault. And you can look at the LR as well if you are in the entry of the Abort mode handler.

    You might want to check how you are generating ECC. Maybe try to adopt what is recommended here:
    processors.wiki.ti.com/.../Linker_Generated_ECC

    Best Regards,
    Anthony
  • Hi Anthony,

    thanks again for your help!

    To be honest, I could not understand how to map the ESM registers to the table where the channel assignments are listed. Does it only list the channels of the status registers? I mean: I see in CCS ESM1 > ShdwStat2 = 0x0000 000C, which means that bit 2 and 3 of the ESMSSR2 are set. In the table I couldn't even find any reference to ESMSSR2 or similar. I did find the two erros that you described which than would mean that bit 2 and bit 3 are channel 2 and 3 of group 2? What about the other registers like ErrKey? How can I know what they mean?

    I did try your suggestion to follow the Linker Generated ECC (I modified the sys_link.cmd file) and I now I get the red LED after starting the debugger, after starting the program with the debugger, and after power off/on. This does not happen all the time. (Maybe I did something wrong with file)

    Sometimes, after power off/on of the target, the red LED stayed off. However, the program was still not working as it should be (the data that was saved in the last run in the EEPROM was somehow corrupted, why?). 

    Since I could not understand the table you mentioned, I tried send through the serial interface the esmError():

        char buffer[132] = "Inital";
    
        sprintf (buffer, "esmError()=%u\n\r", esmError());
        sciDisplayText (UART, (uint8_t *) buffer, strlen(buffer));
    
        sprintf (buffer, "Group 1 ESM status: Chans 95-64=0x%llx  Chans 63-0=0x%llx\n\r",
                esmGetStatusUpper (0, 0xffffffffLL),  esmGetStatus (0, 0xffffffffffffffffLL));
        sciDisplayText (UART, (uint8_t *) buffer, strlen(buffer));
    
        sprintf (buffer, "Group 2 ESM status: Chans 31-0=0x%llx\n\r",
                 esmGetStatus (1, 0xffffffff));
        sciDisplayText (UART, (uint8_t *) buffer, strlen(buffer));
    
        sprintf (buffer, "Group 3 ESM status: Chans 31-0=0x%llx\n\r",
                 esmGetStatus (2, 0xffffffff));
        sciDisplayText (UART, (uint8_t *) buffer, strlen(buffer));

    ... and I could notice that even though the red LED was ON the status returned from esmError() was zero but the Chans 63-0 was sometimes also zero and sometimes 0x80000000000... And viceversa, even though the red LED was OFF the status from esmError was 1.

    After a power off/on, and in those cases where the board started with the red LED in OFF state, I saw the esmError = 1 and tried to connect to it without reseting the target. This action always caused the LED to turn ON and some ESM registers showed values different that zero and still the serial messages were saying that there were no errors. Help? xD

    I don't even know where to start.

    Image 1: After starting the debugger AND before starting the program

    Image 2: after connecting the debugger without resetting the target

    Image 3: after connecting the debugger without resetting the target 2

    Best regards,

    Julio