RL78 ends up at 0xFF0 ?? during random times per power cycle


I wrote a custom driver for the DTC and it has been running great, however at seemingly random points in the program the RL78 eventually ends up at address 0xFF0 with ?? (according to the disassembly in the IAR debugger) . Could this be because my linker files ram start address is 0xFBF00, and I don't offset my start address for the addresses below?

  1. The debugger uses the area FE300H to FE4FFH to store the result of tracing when the tracing function for
    on-chip debugging is in use. Accordingly, use of this area is prohibited while the tracing function is in use.
  2. The debugger uses the area FE500H to FE52FH as a working area when the hot plug-in function is in use or
    when the DTC is in use for the real-time RAM monitor (RRM) or dynamic memory modification (DMM) function.
    Accordingly, use of this area is prohibited while the hot plug-in function is in use or the DTC is in use for the
    RRM or DMM function.

(RL78 F13/F14 user manual per Figure 3-14. Memory Map (R5F10AmG (m = G, L, M), R5F10BnG (n = A, B, G, L, M)))

From what I can tell my software is functioning fine and it's only when adding significantly more functionality that this becomes an issue. Currently I am only using my DTC driver for the simplified I2C peripheral and this works fine with fewer transactions. When attempting to send out more data this issue occurs sometimes as late as 900 seconds into the program runtime.



Parents Reply Children
  • Yes, everything is initialized prior to kicking of the DTC (start watching for corresponded trigger)

  • And the problem appears when the buffers are bigger ?

  • This problem only seems to appear with less time in between transfers, prior to this I would be transferring every 10ms. Now I am transferring data more frequently. I don't believe this is related to buffer size. I also believe JimB may be onto something. Certain actions result in the frequency changing. Such as reordering transfers, removing transfers, etc. Removing transfers makes this non reproduce able. I will check these transfers to see if there is anything problematic

  • Have you tried the high-speed transfer operation of DTC ?

    The high-speed transfer can be realized by allocating the dedicated control data to the SFR area instead of the RAM area. To perform basic operation, normal mode requires five clock cycles to read vector and control data, while high-speed transfer requires one cycle. In addition, to write back control data, normal
    mode requires a maximum of three clock cycles, while high-speed transfer requires one cycle.