• State Not Answered
  • Replies 3 replies
  • Subscribers 14 subscribers
  • Views 231 views
  • Users 0 members are here
Options
Related

Exception happens on core1 while reset triggered on core0

Arlo

Hi all,
After flashing the code on MCU target (R7F702301B) there are two following situations:
1) Sometimes both cores start working properly, but after doing "in target reset" (in Trace32), core1 gets stuck and encounters an exception, the exception codes are mainly FEIC = ox11, FEIC = 0x60, or FEIC = 0xC0.

2) Sometimes as soon as flashing the code on target, just core0 starts working and core1 encounters above mentioned exceptions.

What can be the reason?
Any help is appreciated.

  • 0

    Hi  ,

    are you using a Lauterbach tool to do the flashing?
     

    As most probably known,
        FEIC = 0x11 = SYSERR - A response error occurred in a bus slave at the time of instruction fetching
        FEIC = 0x60 = RIE - Execution of a reserved instruction
        FEIC = 0xC0 = MAE - Misalignment exception

    All of these errors are pointing to a program crash where the program counter PC reaches invalid code flash addresses. Either the PC reach erased code flash (ECC error -> 0x11), invalid code (0x60) or odd jump destinations (0xC0).

    Please check if the reset vectors are set correctly and valid code is present at the RBASE addresses.

    Option Byte settings for operating frequency might be wrong. (OPBT10, OPBT11). E.g. if higher Main OSC frequency is on the PCB than selected, the operating frequency for the CPU might be too high and operation may fail randomly.

    Check for core voltage supply. Weak core voltage supply (e.g. wrong SVR configuration) may cause CPU malfunction. Check for VMONF — VMON Factor Register; Should be zero.

    I hope this helps

    best regards 

    PC_Renesas

  • 0 in reply to PC_Renesas

    1)Yes, reset vectors are set correctly.

    2)Which code should be present at the RBASE addresses? reset handler functions?

  • 0 in reply to Arlo

    RBASE is a read-only register which shows the reset vector (default 0), which menas the CPU start the very first execution at this address. Only if the reset vectors are re-programmed by RFP, the RBASE might be different. (Not very likely, but possible).
    Since Lauterbach is involved too, please reach out to the Lauterbach Support so they are aware of this problem too. 

    One thing have to be taken in mind: A Debugger will always start all CPU cores at the same time. In a real device only one code start fisrt (PE0/ICUM start first and other must be started by SW via BOOTCTRL). This might generate unexpected behavior when relying in SW that PE0(ICUM start first. If the other cores are already operating, but the first core did not initialized the memeory system, the other cores may fail in operation depending on SW outline. Synchronous or asynchronous debugging can be switched in the Debugger to have a workaround for this circumstance.

    Please make sure the OPBT10 oscillator and OPTB11 PLL settings are correct. Please also make sure, that the power supply is high and strong enough, because a weak core voltage may explain this weird behavior.