• State Verified Answer
  • Locked Locked
  • Replies 1 reply
  • Subscribers 12 subscribers
  • Views 212 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

RH850 Reset Reason Unclear

Max Krug

Hello community

Derivative: R7F7016903AFP-C (RH850 KM-S1)

Here's my question:

We are executing an RSS PSA signature verification algorithm in software on our RH850 KM-S1.

When debugging, the software arrives at the algorithm and starts executing it.

If we let the software run without breakpoints, the microcontroller resets and arrives at the reset vector. 

I fail to find the reason for the reset. The RESF Reset Factor Register at FFF8 0760h has only the value of 0x200 which only indicates Power up Reset. All interrupt status registers are zero and don't indicate any occurred interrupts/exceptions.

I tried disabling Watchdog via Option Bytes but the behavior didn't change.

Do you have any suggestions what I can otherwise check for troubleshooting purposes?

Thank you!

  • +1

    Dear Max Krug,

    the RESF register will show all reset reasons until the flags are cleared manually by the software.
    Only a power-up reset is able to clear reset reasons, except Bit 9 (0x200 = Power-up).
    The security enhancement ICUSE of RH850/F1KM-S1 is not able to generate a reset.

    If an unexpected reset occur, the RESF register will show the reset source.
    Any non-maksable or maskable exception would not generate a reset, but a jump to a dedicated service routine. Usually, all exception vectors are defined to jump to an endlees loop ("Unused ISR) in regular start-up demo projects. If there is any (unexpected) exception, The CPU registers FEIC/EIIC would indicate the exception source.
    Depending on the reset/exception source, the peripheral may have additional status registers.

    If neither a reset source is indicated in RESF (before manual clearing) and also nor exception currently executed, there is no reset. Most probably, there is an unexpected program crash (e.g. jump to zero). A stack overflow could also be the reason. Of course, this should be also possible to evaluate with a connected Debugger.

    Please keep in mind that software breakpoints (in opposite to hardware breakpoints) change the code. Software breakpoints will replace the code by a special debug instruction. If you have an algorithm to calculate code flash checksums, they may differ if you use software breakpoints or not. In such a case, it is better to use hardware breakpoints (limited number), as they are not changing the code.

    Best regards