RL78/L13 - CC-RL Compiler runtime issues on E2STudio V6

I have a project for our custom hardware using the RL78/L13 (R5F10WLEAFB - 64k Flash, 4k RAM). I am using E2STUDIO V6.0 and I have installed the CC-RL_V10500 compiler. 

Initially, I have been using the GCC compiler, but with my code growing, I had linker issues even with optimization and so I have moved to using the CC-RL compiler.

I created a new project, used code generator and adding my application files from the GCC project. So, pretty much, the source code is identical except for CC-RL specifics. The code compiles fine and I am running the hardware debug configuration on the target. The problem is that the board reboots repeatedly. The code runs to a point and resets.

I have a set the option bytes as follows: 6effaa84

I have also set IAWCTL = 0x00U;

Since hitting the issue, I have reverted to a more simpler project, which retains all the code generator code with some of my user defined functions for the UART1, and in my main() function, I simply print some text on UART1. This works fine. When I introduce more code, to detect a keypad keypress, I get some unexplained behavior where a function that checks if a key was pressed returns the key pressed or 0xFF if a key was not pressed. This is done by initializing a local variable to 0xFF and changing it to the value of the key pressed and returning this variable. I seem to always get 0x00 returned, when no key is pressed. Anway, after running this code in while loop for some time, the board just resets. This is just one part of the problem.

If I introduce more code, before the key detection and the while loop, where I am using the CSI0 port to write to registers on a transciever chip on the board, again, I hit issues with board resetting when R_CSI00_Send_Receive() is called.

Bear in mind that the equivalent simpler project, when compiled and run using the GCC compiler works perfectly fine. We also have a license for the IAR compiler. I created another project using IAR and, as with the GCC compiler, I can run the build fine on the target. 

My conclusion is there must be some differences in the compiler settings. At the moment, I am running the CC-RL without any compiler or linker optimization. Could there be some invalid memory access?

Where do I start with debugging this issue? I need some pointers.

  • Update - I managed to get the build to run without a reset. This occurred after I had ran up another project using the IAR compiler and after I had fixed some compiler warnings about function prototypes not being defined. I suspect that the problem was with the option bytes not being written correctly possibly and the WDT counter being enabled after reset. Since the other project using IAR, was stable. At this point I am not entirely sure, as I would image that each time I load a new project, the option bytes are erased and rewritten. I'm still concerned that things seemed to fixed themselves without understand the root cause. Could the option bytes not being written correctly, cause an issue here?
  • Hi Sudesh,

    Your case is quite complex and it would take time to replicate the error or at least confirm what causes the microcontroller to reset. Please give the forum more time to analyze your case. Thanks for understanding.

    RenesasRulz Forum Moderator
  • Sudesh,

    How is your project progressing? It sounds like your WDT might be the cause.
    Have you had any luck?

    Mike Clements
    RenesasRulz Moderator

  • Hi Mike,

    Currently, I don't see the reboot when I use E2STudio to flash the build i.e. "launch in debug mode" which I know will write the file to flash as well as write the correct option bytes. Using the free version of Renesas flash programmer, there is no option to set the option bytes, so these could get overwritten. Furthermore, I am printing out the Reset Status Register and POR Status Register on boot up in order to check the status if I do experience a reboot.

  • Hi Mike,

    I've experienced the reboot again today. Both the RESF and PORSR registers are 0. I am reading and printing these out in my main() function. I have also set PORF bit in the PORSR register to 1 in R_Systeminit(). I am reading these registers once in the R_CGC_Get_ResetSource() function and storing them in a global variable, which I then print on the uart in main().

    I was hoping to see at least 1 of the bits in the RESF register set to 1. But each time the board reboots, the register is always zero. The reboot occurs in the main() after R_MAIN_UserInit() is called and after some additional peripherals and application specific functions.

    In the R_MAIN_UserInit(), I am intializing some port pins that control the peripherals, turn on the LCD Voltage, initialize UART1 for receiving and then start the uart. I also call  R_CSI00_Start() and finally EI() to enable interrupts. I then initialize the RF front end (radio) connected to CSI00 and call v_LCD_Start()/

    I then print out the variables storing  RESF and PORSR registers and my application version on the uart. The reboot always occurs in the middle of printing out one of the lines of debug.

    The debug prints are as follows (using macros):

    DEBUG_DEBUG("Reset Status Register: 0x%x\n\r", uc_reset_flag);

    DEBUG_DEBUG("POR Status Register: 0x%x\n\r", uc_porsr_flag);

    /* Print Firmware Version Info */

    DEBUG_INFO("Intelli-Meters Comet\n\r");

    DEBUG_INFO("Version: %s\n\r", FIRMWARE_VERSION);

    The DEBUG_DEBUG macro, prepends "[DEBUG]" to the output string and the DEBUG_INFO macro prepends "[INFO]".  

    On my uart log capture, I see the following output:

    [DEBUG]Reset Status Register: 0x0
    [DEBUG]POR Status Register: 0x0
    [INFO]Intelli-Meters Comet
    [INFO] ---> reboot happens here

    This pattern repeats itself over and over. The reboots always occurs at the same point.

    Any other ideas on the debugging this further. 

    PS: Running through the debugger, there is no reboot.

  • Usually uncontrolled reboot could have 3 causes:
    (1) Uncontrolled watchdog timer overflow.
    (2) Stack overflow.
    (3) Insufficient power supply for the hardware. When to may peripherals are switched on the voltage breaks down and causes a power on reset.

    The register value would look like possibility 3.
  • Sudesh,

    Have you found what is causing your reboot?

    I tend to agree with FrankL.
    It is sounding like you are trying to drive to many peripherals at the same time.

    Let us know what you find.

    Mike Clements
    RenesasRulz Moderator
  • Mike,

    I have been finding it difficult to readily reproduce the problem. What I did today, was to confirm that I'm printing out the RESF and PORSR correctly by enabling the WDT again and deliberately forcing a reset by sitting in a while loop. I have set PORF to 1 in the initialization sequence.
    I see that the WDTRF and PORF bits are set after the reset.

    What I am doing now is to monitor the VDD line on scope and check if VDD drops.
    Also, while looking at the operation of the reset circuit in the RL78L13 user manual, I see that user option byte 000C1H, enables or disables the LVD setting.

    My user option byte settings are:

    C0: 0x6F
    C1: 0xFF
    C2: 0xAA
    C3: 0x84

    For C1, does this mean that the LVD is disabled? If so, given that we are not controlling the reset signal while running stand alon (i.e. without the debugger), would we need to set the LVD option bytes and if so, what is the typical value?
    Could this be the reason for the reboot i.e not setting the LVD option byte correctly?

  • One other question: I'm also looking at the initialization sequence from the code in R_Systeminit() to my R_MAIN_UserInit(). In my R_MAIN_UserInit(), I'm calling the following:
    R_LCD_Voltage_On(), R_UART1_Receive(), R_UART1_Start(), EI() and after this, R_IT_Start (). I've seen sample code where EI() is called first before any _Start() functions. Would this be a problem?
  • What does this mean: "we are not controlling the reset signal while running stand alon". You have to have a RESET circuit providing the reset signal to the processor. So you do control it.
    C1=0xFF means LVD is switched off. You do not really need LVD if your application is not battery operated or if it does not matter to your application if the processor unexpectedly stops operating due to battery failure.
    As for the initialization sequence, this is for you to answer. How long do you think it takes after R_IT_Start and R_UART1_Start that the first interrupt occurs? Will there be sufficient time to enable interrupts using EI()? If not, does it matter to your application if the execution of the interrupt routine is delayed? Would the delay be so big that more than 1 interrupt of any peripheral occurs thus causing loss of interrupts?

    I appreciate your efforts trying to describe your problems. However, such descriptions are always only highlighting some very small effects of your software, but never give the complete picture of what is going on. For example, all your descriptions don't say anything about stack sizes, interrupt load, runtime of interrupt functions blocking the processor, interrupt nesting being used or not, ... . It is more or less impossible to provide substantial help without having a project at hand showing the behavior. I would propose to get in touch with the local Renesas support and talk to them, if possible have them take a look at your application.