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.
Sudesh, How is your project progressing? It sounds like your WDT might be the cause. Have you had any luck? Mike Clements RenesasRulz Moderator
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.
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); MOVW AX,#LOWW(__STACK_ADDR_END);$ELSE ; for CC-RL V1.00; MOVW AX,#LOWW(_stackend);$ENDIF; 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.
Can you please tell me how u resolved it and how to initialize the stack? I am also facing the same issue
i am using GCC compiler in e2studio
for RL78 MCU