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?
  • 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.

  • Thanks for clarifying about the reset circuit. We do indeed have a reset circuit after looking at the schematic. We are currently running on batteries, but we are modifying the board to run of an external DC adapter, so we don't need to run on batteries for our testing purposes. I have experimented yesterday with enabling the LVD in the option bytes and I do see the chip being held in reset if the VDD supplied by the batteries is below the set thresholds. It is good to know how this operates. In any case, the reset still occurs intermittently. We've hooked up a scope on the VDD line and connected up to a bench supply with the current limiting set pretty high. We saw that when the reset occurs, we drawing about 60mA. This is well within the TS911 regulator output of 250mA. So' for now we've rules out the regulator dropping out.

    As for the interrupts, I think, we do want interrupt enabled before any peripherals are started, so, I will move the EI() to start of the initialization. My concern was more around spurious interrupts resulting in some sort of reset. I guess, however, this is unlikely given that the reset status is always 0.
  • Hi Frank,

    I've managed to find the cause of the reset to be due to a RAM parity error.  What I found was that when I generate the projected in E2STudio using the code generator, R_Systeminit() in r_cg_systeminit.c calls R_CGC_Get_ResetSource() to save the reset source. I used some global variables to store the reset source, to be printed out later in my main function.

    The problem is that after  R_Systeminit(), the code returns to cstart.asm and then zeros out the BSS section. So, these variables were always showing as 0, which was misleading. When testing the watchdog reset, I was stepping through the code and breaking inside R_CGC_Get_ResetSource().  Since the reset for the RAM partity is hard to reproduce, and never showed up when stepping through the debugger,  I now call R_CGC_Get_ResetSource() and now I get the actual values. When the reboot occurs, I read:

    RESF  = 0x0 and PORSR = 0x1

    I see that the reset on RAM parity is enabled by default. I have also come across this link while searching for RAM parity on the RL78: 

    Do I need to be careful in RAM parity error detection function of the MCU?

    So, what do I need to do to find the cause of the RAM parity error? Should I also follow the advice in this link and uncomment the commented out stack initialization code:

    ; initializing stack area
    ;$IF (__RENESAS_VERSION__ >= 0x01010000)
    ;$ELSE ; for CC-RL V1.00
    ; MOVW AX,#LOWW(_stackend)
    ; CALL !!_stkinit

  • Yes, you should follow the advice in the other FAQ. The reason is that when using RAM parity error you must not use any not initialized memory area. By default stack area is not initialized and may contain parity errors from the power on reset.

  • Ok, I see. Just to further clarify what the FAQ is saying, by default, reset on parity check failure, is enabled. Also, RAM parity checking cannot be disabled. So, either I disable the reset or ensure the stack is initialized. So If I enable the stack init code, keeping everything else the same, this should resolve my issue?
  • Sudesh,

    Has initializing your stack solved your issue?

    Mike Clements
    RenesasRulz Moderator
  • Yes it does. Although I'm still not clear why the stack init code is not turned on by default? Why is that so?
  • Yes, initializing the stack has solved the issue.
  • Can you please tell me how u resolved it and how to initialize the stack? I am also facing the same issue

Reply Children
No Data