This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMDS64EVM: TMDS64EVM, AM64xx

Part Number: TMDS64EVM
Other Parts Discussed in Thread: SYSCONFIG

Tool/software:

Hello,

Issues :

  1. The app works in debug mode but fails the release mode (when burn the app to the flash). The execution error at power ON as follows : (on terminal windows)

“Image loading done, switching to application …

ERROR : Bootloader rprcImageLoad: 317: Application image has a load address (0x70020000) in the SBL reserved memory range!!”

The issue was when need the HEAP memory needed beyond the capacity of MSRAM(2MB). So

In the Memory Configuration Section, under General I increase the heap size as :

And under Section, Memory Segments, I  split across memories with DDR as :

My application is to read the user’s data in the flash region starting 0x100000 and ending at 0x280000 with the app to be programmed at 0x80000 as per “default_sbl_ospi.cfg” file. In my application I will load this user’s data into the pointer variable (in the heap memory).

With this configuration, I can malloc the pointer variable in my application and it works fine with

the debug mode. But it fails the app at Power ON when burning the release to the flash as shown.

  1. The remedy for the flash execution problem was to reduce the heap to fit in MSRAM for the app to work with flash and not using the extension into DDR4 above is to transfer the user’s data in chunks and mimic the flash read of “ospi_flash_io” example. Here is the information :

#define APP_OSPI_FLASH_BASE (0x100000) // start address of User’s data

#define HEAP_SIZE                    (262144U)

#define APP_DATA_SIZE         (1241804U)     // This is User’s data size in the flash

uinit32_t quotient, remainder, byteUsed;

uint8_t *prgmBuffer __attribute__((aligned(32U))) = (unit8_t *)malloc(HEAP_SIZE);

// so the heap for the pointer *prgmBuffer is now reduced

……

quotient            = APP_DATA_SIZE/HEAP_SIZE;

remainder        = APP_DATA_SIZE % HEAP_SIZE;

               // Now is the loop to get the data in chuck from flash each of 256KB instead of one big heap of

// more than 1.5MB

               for (uint8_t loopcnt = 0; loopcnt <(quotient+1); coopcnt++)

               {

byteUsed          = (loopcnt == quotient)? remainder : HEAP_ZISE

offset = APP_OSPI_FLASH_BASE + (loopcnt*HEAP_SIZE);

Flash_offsetToBlkPage(gFlashHandle[CONFIG_FLASH0], offset, &blk, &page);

status = Flash_read(gFlashHandle[CONFIG_FLASH0], offset, prgmBuffer, byteUsed);

…….

// application code continues

…….

               }              // the offset is page alignment for sure

The problem was the loop runs the first loopcnt = 0 and then for the second loop the Flash_read() was hanged (with break point verification). So added the Flash_Reset(gFlashHandle[CONFIG_FLASH0]) before Flash_offsetToBlkPage() to no avail.

As per “ospi_flash_io” the example code the flash read of the second offset was fine and don’t know why it was stucked here.

I need help how to resolve this.

 

  1. This is minor but curious. The setting of Memory Region for FLASH in the sysconfig was :

Start Address : 0x60100000

Size                     : 0x80000

What is it at 0x60100000 instead of even boundary of 0x60000000 and why the size only 0x80000 (512K) instead of 0x4000000 (64MB or 512Mbit) of the device on the board ?

  • Hi,

    Let us start with the SDK version you are on. Please let me know.

    Regards,

    Vaibhav

  • mcu_plus_sdk_am64x_10_01_00_32

  • Hi,

    status = Flash_read(gFlashHandle[CONFIG_FLASH0], offset, prgmBuffer, byteUsed);

    Each time this line is executed, please give me the value of offset. prgmBuffer and byteUsed in every loop.

    Please send me your default_sbl_ospi.cfg file as well.

    Regards,

    Vaibhav

  • The second loop is stuck at Flash_read() and never get to break point.

    #define APP_DATA_SIZE               (1241804U)

    #define HEAP_SIZE                         (262144U)

    uint8_t *prgmBuffer __attribute__((aligned(32U))) = (uint8_t *)malloc(HEAP_SIZE);

    Here is the CIO information :

    quotient and remainder are : 4 , 193228

    Loop is, offset, prgmBuffer, byteUsed : 0, 1048576, 1879874224, 262144

    Loop Cycle is here!!!

    Loop is, offset, prgmBuffer, byteUsed : 1, 1310720, 1879874224, 262144

    ------------------------------------

    Here is the default_sbl_ospi.cfg

    #-----------------------------------------------------------------------------#
    #                                                                             #
    #      DEFAULT CONFIGURATION FILE TO BE USED WITH THE FLASHWRITER SCRIPT      #
    #                                                                             #
    #-----------------------------------------------------------------------------#
    #
    # By default this config file,
    # - points to pre-built flash writer, bootloader for this EVM
    # - The application image points to relative path of the ipc echo application image for this EVM
    #   - Make sure this application is built before running this script
    # - You can customized this config file to point to your own bootloader and/or application images
    # - You can use --operation=flashverify if you just want to verify the flash contents and not flash the file.
    #
    
    # First point to sbl_uart_uniflash binary, which function's as a server to flash one or more files
    --flash-writer=sbl_prebuilt/am64x-evm/sbl_uart_uniflash.release.hs_fs.tiimage
    
    # Now send one or more files to flash or flashverify as needed. The order of sending files does not matter
    
    # Program the OSPI PHY tuning attack vector
    --operation=flash-phy-tuning-data
    
    # When sending bootloader make sure to flash at offset 0x0. ROM expects bootloader at offset 0x0
    --file=sbl_prebuilt/am64x-evm/sbl_ospi.release.hs_fs.tiimage --operation=flash --flash-offset=0x0
    
    # When sending application image, make sure to flash at offset 0x80000 (default) or to whatever offset your bootloader is configured for
    #--file=../../examples/drivers/ipc/ipc_rpmsg_echo/am64x-evm/system_freertos_nortos/ipc_rpmsg_echo_system.release.appimage.hs_fs --operation=flash --flash-offset=0x80000
    
    # send the XIP image for this application, no need to specify flash offset since flash offset is specified within the image itself
    #--file=../../examples/drivers/ipc/ipc_rpmsg_echo/am64x-evm/system_freertos_nortos/ipc_rpmsg_echo_system.release.appimage_xip --operation=flash-xip
    
    # Put your application here instead of default APP image
    --file=C:/Users/user1/workspace_ccstheia/myApp/Release/MyApp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs --operation=flash --flash-offset=0x80000
    
    --file=C:/Users/user1/workspace_ccstheia/MyApp/Release/MyApp_r5fss0-0_freertos_ti-arm-clang.appimage_xip --operation=flash-xip
    
    # Put your FPGA Configuration here 
    --file=C:/Users/user1/Desktop/AppData/User_Data.bin --operation=flash --flash-offset=0x100000
    
    

  • Hi,

    Thanks for your patience.

    Loop is, offset, prgmBuffer, byteUsed : 0, 1048576, 1879874224, 262144

    Loop Cycle is here!!!

    Loop is, offset, prgmBuffer, byteUsed : 1, 1310720, 1879874224, 262144

    Can you check if the MPU ARMV7 configurations contain the region starting from 0x60000000?

    If not defined its okay, if defined then can you tell me if the region 0x60000000 is cached or not?

    Regards,

    Vaibhav

  • Interesting that I change Region Attributes from Cached to Non-cached or Strongly Ordered then the loop is working now. Could you explain to difference

    between Non-Cached and Strongly Ordered ?

  • Interesting that I change Region Attributes from Cached to Non-cached or Strongly Ordered then the loop is working now. Could you explain to difference

    between Non-Cached and Strongly Ordered ?

    I am pretty glad this came out. 

    I had a suspicion around the region from 0x60000000 being cached as I have mentioned here in the previous response:

    Can you check if the MPU ARMV7 configurations contain the region starting from 0x60000000?

    If not defined its okay, if defined then can you tell me if the region 0x60000000 is cached or not?

    So the region for OSPI should not be cached, the reason being the data in the region can be stale and hence, we have to avoid using cached. One follow up question from you could be cached can increase the data read speed, well for that front, we go the other route, where we increase the frequency, use Phy mode and use DMA mode in combination to achieve higher read speeds.

    Could you explain to difference

    between Non-Cached and Strongly Ordered ?

    I would like you to refer the ARM documentation to have a read on these two. Even after reading if you are left with some doubts, please let me know.

    Regards,

    Vaibhav