Bootswapping operation is very unstable, even more in release

Hi everyone,

Context of the project

I'm working on a bootloader project based on RL78. I set my memory like this : 

This idea is to jump from application to bootloader when I want to update the application and to jump from bootloader to application when I'm finished with the upload.

Major Issue

I'm able to start bootloader, flash the program, jump to application, jump to bootloader and flash program again. But this is ok like 50% of the time in DEBUG. The first start and flash is always working, the first jump is almost always working and after that it depends.

In release mode, it is even worse. I can start bootloader, flash the program and most of the time I can't even jump to the application

How did I code that ?

I'm based on the renesas FSL library and working on the R5F10DPJ microcontroller. To perform the bootswapping, I'm using this function : 

void Flash_SwapBootCluster()
{
	fsl_u08 fsl_status;
	UINT32 wait;
	
	// Open FSL and prepare all functions
	FSL_Open();
	FSL_PrepareExtFunctions();

	// Invert bootflag to start correct bootloader and close FSL
	fsl_status = FSL_InvertBootFlag();
	while(fsl_status != FSL_OK)
	{
		fsl_status = FSL_InvertBootFlag();
	}

	// Close FSL
	FSL_Close();

	/* Delay */
	wait = (UINT32)0;
	while(wait < (UINT32)10000)
	{
		wait++;
	}

	// Perform swapping of bootcluster
	fsl_status = FSL_SwapBootCluster();
	while(fsl_status != FSL_OK)
	{
		fsl_status = FSL_SwapBootCluster();
	}
}

I start to be out of idea, am I doing something wrong with this boot swapping ?

Thanks in advance and have a good day !

Parents Reply Children
  • Alright I understand it was for the option byte sorry.
    Behavior is the same and now (before I change the option byte) the debug was completely unstable and application to bootloader is not working anymore (but bootloader to application always working)

    Edit : Really sorry, I know it's a weird issue and I struggle to give more information to be clearer

  • Hi again, I'm bringing some news.

    For now, I was able to stabilize the process in DEBUG mode, based on the chart you sent me. So I'm just inverting boot flag and then I force a soft reset using an infinite loop and the watchdog reset.

    When I go in release mode, I can communicate with the bootloader to update the flash but when jumping from bootloader to application, the communication ends and everything is broken. It's like the MCU reset and remains in reset, without initializing the board. I'm still investigating

  • Hello,

    Actually the reset should be a software reset by FSL_ForceReset as in the provided diagram above. Watchdog reset is not a software reset.

    In standalone operation also disable this option:

  • Hi, thanks for your answer

    According to RL78/D1A documentation, both watchdog reset + illegal instructions are software reset and this seems to be the purpose of FSL_ForceReset. But I followed your guidelines and removed the infinite loop to just let the FSL_ForceReset function

    I also disabled on-chip debug through the option byte (0xC3)

    Behavior is still the same : jump from bootloader to application blocks the MCU only in release mode

  • It could be due to RAM parity error. Please initialize RAM as I have mentioned on this post:

    community.renesas.com/.../ram-parity-error-in-rl78-d1a-controller

  • Hi, thanks again for you answer.

    I need to reserve SELFRAM for the FSL so I added this in the linker file : 

    -Z(CODE)SELFRAM=[FBF00-FC2FF]

    Do you want me to update the linker file or directly the cstartup.s87 file ? (which is reading my linker file). I start to struggle how to organize my linker file between FSL segment, SelfRam for FSL_Write and RAM Initialization

    I have this in my cstartup.s87 file :

            ; Init stack segment for as the generated code may sometimes
            ; access the 4th byte of a return address before it is initialized
            MOVW    HL, #sfb(CSTACK)
            MOVW    BC, #LWRD(sizeof(CSTACK))
            CMP0    C
            SKZ
            INC     B
            MOV     A, #0xCD        ; 0xCD to fool C-SPY's stack limit check
    loop_s:
            MOV     [HL], A
            INCW    HL
            DEC     C
            BNZ     loop_s
            DEC     B
            BNZ     loop_s
    
            MOV     CS, #0

    And, in my linker file : 

    //-------------------------------------------------------------------------
    //      Stack segment.
    //-------------------------------------------------------------------------
    -Z(DATA)CSTACK+_CSTACK_SIZE=FC300-FFE1F

    EDIT : This is only for the bootloader project, not the application

  • You can reserve self RAM are from this setting:

    No need to modify the linker manually.

  • I'm on IAR,I don't have this option :/

  • I forgot this, apologies. Then update the linker file - not cstart file- and reserve area FBF00H- FC2FFH.

    The self RAM area reservation is a different thing than RAM initialization. The self RAM is reserved for the flash libary while the RAM must be initialized so that a RAM parity error does not occur. Not all RAM areas are initialized in the startup.

  • Alright then I update this in both of my linker file : 

    //-Z(DATA)CSTACK+_CSTACK_SIZE=FC300-FFE1F
    -Z(DATA)CSTACK+_CSTACK_SIZE=FBF00-FFEE0 // Full RAM init

    and

    -Z(CODE)SELFRAM=[FBF00-FC2FF]

    The first update will perform full RAM initialization according to the cstartup script that I don't need to modify.

    The second update ensure that the SELFRAM is reserved

    Am I right?