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

Hello,

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.

Thanks,

tempre

Parents
  • Hello,

    If the IAR linker file defines the RAM address to 0xFBF00 then this is wrong. The RAM on your device starts at 0xFDF00.

    What exists on 0xFF0 ? Do you see what command exists on this line on the disassembly view ?

    The areas you mentioned are reserved if the respective debugger functions are enabled, I do not think this is the cause of the problem.

  • Apologizes, I referenced the incorrect micro. This the correct micro with Figure 3-16. Memory Map (R5F10PmH (m = G, L, M, P)) with the correct RAM address start of 0xFBF00. There is no command in the disassembly view it's purely just followed by question marks (??) stopping/hitting a breakpoint any time prior to this occurrence results in a correct disassembly view. When it fails there is no assembly instruction on the disassembly just ??.

  • From what I can tell my software is functioning fine and it's only when adding significantly more functionality that this becomes an issue.

    This makes me think of a possible stack overflow. Have you tried to increase the stack size in the linker file ?

  • This was my original assumption, I increased the stack size from 200 --> 512 and the issue persisted, would you recommend further increasing it? 

Reply Children