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
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("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.
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.