• State Verified Answer
  • Replies 35 replies
  • Answers 1 answer
  • Subscribers 18 subscribers
  • Views 8095 views
  • Users 0 members are here
Options
Related

Bootswapping operation is very unstable, even more in release

Lazy Dridri

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
  • 0 in reply to AZ_Renesas

    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

  • 0 in reply to Lazy Dridri

    You can reserve self RAM are from this setting:

    No need to modify the linker manually.

  • 0 in reply to Lazy Dridri

    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.

  • 0 in reply to AZ_Renesas

    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?

  • 0 in reply to Lazy Dridri

    The RAM initialization happens during startup in the cstart file as I mentioned on the post I shared. The RAM initialization has nothing to do with linker file.

    The cstart file will just fill the RAM with an initial value so any RAM parity errors are prevented.

    The linker will reserve the self RAM area so that nothing else is placed there so the flash library can use this are for its operations.

  • 0 in reply to AZ_Renesas

    My linker file is used to set the value of the stack, to process the RAM initialization through the assembly code you mentionned in the other post.

    I reserved selfram in both of my linker script but still, everything works in debug and not in release, always blocked after the jump to application.

    Maybe I can add more context to my project:

    1. I'm flashing a first program, the bootloader, which needs to update the flash for the second program

    2. To communicate with it, we use CAN bus. So after flashing the bootloader, I send data to flash the program (which is boot cluster 1 and application)

    3. When finished, I jump from bootloader to application

    4. I send a frame test to check if the application answers. In debug, it always answer. In release (which I program using a .s19 file on RFP), the frame I send is never received

  • 0 in reply to Lazy Dridri

    Can you show what modifications have you done in the cstart file to initialize whole RAM ?

  • 0 in reply to AZ_Renesas

    I did no modification.

    My cstartup is like this (at least the part similar to the other post) : 

    ?C_STARTUP:
`@cstart`:
__program_start:
        DI

        MOV     A, #(_NEAR_CONST_LOCATION & 1)  ; Near/Far, set mirror area
        MOV1    CY, A.0
        MOV1    PMC.0, CY
        
        MOVW    SP, #sfe(CSTACK)


        ; 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, through the linker file, I update the CSTACK value:

    //-------------------------------------------------------------------------
//      Stack segment.
//-------------------------------------------------------------------------
-Z(DATA)CSTACK+_CSTACK_SIZE=FBF00-FFEE0

  • 0 in reply to Lazy Dridri

    The RAM will not be entirely initialized with the default cstart file.

    Please modify according to this post:

    https://community.renesas.com/automotive/rh850/f/rh850-forum/33274/ram-parity-error-in-rl78-d1a-controller

    As you can see my cstart file covers the entire address range of RAM - not only stack.