MSPM0L1306: How to generate a single .out file of dl_flashctl.c

I don't understand your questions very well.  I'll focus on just one.

Bian johnny said:

I do not know how to generate flash driver code which run in RAM into a single .out.

What overall problem do you want to solve?  Why do you think you need a single .out file?

Thanks and regards,

-George

Hi George,

Thanks for help. It's requirement of bootloader. The flash driver code which must be saved into a single file must be download to RAM.

I find DL_FlashCTL_executeCommandFromRAM() is in address 0x20000758 when it's in debug state.

The save RAM content to a file operation: Right click and select 'Save Memory' with special address and length, then to required file type. I have done this. If you have another method please share me.

My question now are:

1, Does function DL_FlashCTL_executeCommandFromRAM() is the only flash drive code which is run in RAM?

2, Is the code of DL_FlashCTL_executeCommandFromRAM() with address 0x20000758 to 0x20000BFF (The address is from Memory Browse in debug state)? In my opinion it's a little big.

3, The function DL_FlashCTL_executeCommandFromRAM() is included in code now. How to exclude generated content of this function?

    Does it ok with comment the code in DL_FlashCTL_executeCommandFromRAM(), and download same comment of below picture into address 0x20000758?

Hi Bian,

Are you trying to avoid using DL_FlashCTL_executeCommandFromRAM() due to its "size" in the application?

I also wanted to clarify that application code is loaded to FLASH, not RAM.

Best,

Owen

Hi Owen,

There are 2 separate (app and flash driver) part to be download with bootloader.

App code is downloaded into FLASH, flash drive is downloaded and run into RAM.

The flash drive download into RAM when update application code is the requirement from customer. In my opinion it's for safety.

Hi Bian,

Thanks for the clarification. I believe this involves modifying the linker file. I will look into this for you and get back to you. 

Best,

Owen

Hi Bian,

For reference on how to modify the linker file, I would suggest looking at the secondary_bsl_uart example in the SDK. You can compare it to the default linker file to see what needs to be updated.

/*
 * Copyright (c) 2024, Texas Instruments Incorporated
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 * *  Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 *
 * *  Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.
 *
 * *  Neither the name of Texas Instruments Incorporated nor the names of
 *    its contributors may be used to endorse or promote products derived
 *    from this software without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
 * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
 * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
 * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
 * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
 * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
 * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
 * OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
 * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
 * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
 * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */

-uinterruptVectors

/*----------------------------------------------------------------------------*/
/* Memory Map                                                                 */

MEMORY
{
	FLASH_SBSL_INTVEC(RWX)  :	 org = 0x00001000,      len = 0x00000040,
	FLASH_SBSL_START(RWX)   :	 org = 0x00001040,      len = 0x00000040,
	FLASH_SBSL(RWX)   		:	 org = 0x00001080,      len = 0x00001F80,

    SRAM(RW)				:    org = 0x20000000,      len = 0x00001000,

    BCR_CFG		 		    : 	 org = 0x41C00000,      len = 0x00000080,
    BSL_CFG				    : 	 org = 0x41C00100,      len = 0x00000080,
    FACTORY_CFG		  		: 	 org = 0x41C40000,      len = 0x00000200,
}

/*----------------------------------------------------------------------------*/
/* Section Configuration                                                      */

SECTIONS
{
	.intvecs			: PALIGN(8) {} > FLASH_SBSL_INTVEC
	.sblStart			: PALIGN(8) {} > FLASH_SBSL_START

    GROUP(FLASH_MEMORY) {
        .text          	: PALIGN(8) {}
        .const         	: PALIGN(8) {}
        .cinit         	: PALIGN(8) {}
        .rodata			: PALIGN(8) {}
    } > FLASH_SBSL

    GROUP(SRAM) {
    	.vtable 		: {}
        .data          	: {}
        .bss           	: {}
   } > SRAM

	.TI.ramfunc   : load = FLASH_SBSL, palign(8), run=SRAM, table(BINIT)

    .stack  :   > SRAM (HIGH) SIZE(BSL_CI_stackSize)

    .factoryConfig          : {} > FACTORY_CFG
    .BCRConfig              : {} > BCR_CFG
    .BSLConfig              : {} > BSL_CFG
}

I believe to have flash driver code in RAM, all you need to do is use the "FromRAM" DriverLib functions. For example, when running the DL_FlashCTL_eraseMemoryFromRAM, the code will be loaded from flash to RAM.

Here are the MSPM0 Bootloader User's Guide and MSPM0 Bootloader Implementation Guide if you would like more information on this topic.

Best,

Owen

Hi Oven,

I had studied link in your replay. thanks!

The flash drive code in RAM is ok.

The code of DL_FlashCTL_executeCommandFromRAM() between address 0x20000758 and 0x20000BFF (The address is from Memory Browse in debug state, see below picture).

The content of DL_FlashCTL_executeCommandFromRAM() is still included in RAM after the content in function is commented out (the same as below picture).

I want to implemented:

The content between address 0x20000758 and 0x20000BFF is blank after MCU run.

The content in address 0x20000758 and 0x20000BFF is written with received data from LIN.

How to comment the content in DL_FlashCTL_executeCommandFromRAM()?

Hi Bian,

I'm not sure why the function isn't clearing from that region of memory. It's possible that if you have calls to FromRAM DriverLib functions, which all call the DL_FlashCTL_executeCommandFromRAM() function.

Does your LIN data have to be between 0x20000758 and 0x20000BFF? I would suggest storing the LIN data at a different address if possible. You can adjust the linker file to allocate regions of memory for this. In code you can also just use a pointer instead of specifying a RAM address.

Best,

Owen

Hi Owen,

The LIN data address is auto generated, I do not known how to define the address. Do you have some ideas about it?

thanks

johnny

Hi Bian,

The LIN data is stored in the peripheral registers, not Flash or RAM. In the Technical Reference Manual, it is stated that this region begins at 0x4000.0000:

In the UART Registers table:

You can also reference the SDK examples lin_commander and lin_responder for implementation.

Is this what you are looking for?

Best,

Owen

Hi Owen,

It's not about LIN.

I want to do like below steps:

1, The RAM address of DL_FlashCTL_executeCommandFromRAM() is between 0x20000758 and 0x20000BFF in current code. Then save the content of whole address into 'flashdrv.hex'.

2, Next i comment the content in DL_FlashCTL_executeCommandFromRAM() and complier pass

3, Next download 'flashdrv.hex' into RAM address 0x20000758 and 0x20000BFF.

Is there any risk with upper operation? If yes, please give your suggestion. Thanks!

br

johnny

Hi Bian,

I'm not sure if I'm understanding the steps, but here's how I am interpreting this.

• You want to save the DL_FlashCTL_executeCommandFromRAM() function as a hex file?
  
  
• Why are you commenting out the implementation of the function? This will compile but the code will not execute as expected.
  
  
• You want to put the code back into the address?
  
  
• What is the idea behind doing this?

It seems to me that you are trying to remove something just to put it back in the same place?

Best,

Owen

Hi Owen,

• You want to save the DL_FlashCTL_executeCommandFromRAM() function as a hex file? yes
  
  
• Why are you commenting out the implementation of the function?  yes. This will compile but the code will not execute as expected. 
  
  
• You want to put the code back into the address? Yes, The code will execute same as DL_FlashCTL_executeCommandFromRAM() comment before. 
  
  
• What is the idea behind doing this?  It's customer requirement. the flash driver must be download into RAM when app code need reflash.
• It seems to me that you are trying to remove something just to put it back in the same place?  yes

Hi Bian,

Thanks for clarifying. I think I am starting to understand now.

Are you trying to run a flash loader from RAM?

I came across this E2E thread that goes over running in RAM. Is this helpful?

Since the compiler doesn't naturally put code into RAM, I think you could also update the linker file to do this, however this is something I'd need to look into. You may even be able to load your program into flash, generate the hex, and load that hex into RAM, but there may be some addressing risks since it would be running in different location than it was built for.

Best,

Owen