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.

Trouble loading FreeRTOS Image into higher RAM address for RM57x

Other Parts Discussed in Thread: HALCOGEN

Hello,

I am having trouble trying to step through the FreeRTOS example project provided for development with the RM57L843ZWTT. I work for a 3rd party programming company, so this development will eventually be used on our programming platform. I am using CCS Version: 6.1.2.00015 and generated the files from HALCoGen 04.05.01.

I have the device connected to the XDS100v2 debugger we have in house, and I can run the example_freeRTOSBlinky project without any issues by downloading the image to flash. The issue is we need to develop a project to erase/program/verify the flash so we need this to execute from RAM. I also cannot use the feature to swap the flash and ram because our software currently requires a higher RAM address and the motorola file I am generating needs to use the higher RAM location.

So, I manipulated the linker command file to move the relevant information to RAM address space, and I can build and connect to my target. At this point I am getting a 'No source available for "0xc750" ' or 'No source available for "0xC" ' error. If I ignore this and try to load my .out file I get the following failure:

CortexR5: Trouble Writing Memory Block at 0x8000000 on Page 0 of Length 0x7ff0: (Error -1065 @ 0x0) Unable to access device memory. Verify that the memory address is in valid memory. If error persists, confirm configuration, power-cycle board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 6.0.14.5)
CortexR5: File Loader: Verification failed: Target failed to write 0x08000000
CortexR5: GEL: File: C:\myWorkspace_RM57L_v1\freeRTOSBlinky\Debug\freeRTOSBlinky.out: Load failed.

My first goal is to just get the project running from RAM at the higher address range. I've attached my .cmd file and would appreciate some feedback on this development.

Regards,

Fernando Guillen

6253.HL_sys_link.zip

  • Fernando

    Try issuing a system reset through CCS before downloading your code. The MPU setting may be a problem.

    You need to be really careful with what you are trying to do because the exception vectors cannot be relocated to SRAM, the are at a fixed address (0x0000 0000) and this is always an address in the Flash.

    I think trying to run a FreeRTOS project without using the vector table is going to be a challenge for you...
  • Hi Anthony,

    Thanks for the feedback.

    I attempted the CPU reset before loading my program, but I still get the same error. I don't specifically need to run the FreeRTOS project, it just seems like a good starting point. I just need a project that can toggle the gpio, and then I can add the F021 API to it.

    Is there any simple gpio or flash project I can use as a starting point that can deal without using the vector table, or a way for me to adjust the FreeRTOS project to do it?

    Thanks

  • Fernando,

    You can pick one of the other examples that comes with HalCoGen.

    If you want to see the F021 API in use from SRAM then one of the 'bootloader' application notes might be appropriate.
    (there are a bunch of them in the product folder under the technical docs tab... )
  • Hi Anthony,

    I tried just creating a project with only one driver enabled. The GIO driver and I used the non FreeRTOS device selection when creating the RM57L843ZWT HALCoGen project. However, I still get the same error as before, when I try to download my program:

    CortexR5: Trouble Writing Memory Block at 0x8000000 on Page 0 of Length 0x20: (Error -1065 @ 0x0) Unable to access device memory. Verify that the memory address is in valid memory. If error persists, confirm configuration, power-cycle board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 6.0.14.5)
    CortexR5: File Loader: Verification failed: Target failed to write 0x08000000
    CortexR5: GEL: File: C:\myWorkspace_RM57L_v2\GPIO\Debug\GPIO.out: Load failed.

    As far as the bootloader app note and other documentation, I see the bootloader documentation for UART, SPI, or CAN plus the source code.
    I tried getting this to work on a previous Safety Microcontroller with mixed results. If possible I would like to get a more simple project working first, and then I could add elements of this.
    Is this bootcode not present on the device from the factory? These projects need to be built and then downloaded, correct?

    Regards,
    Fernando
  • Fernando,

    Try the instructions listed here e2e.ti.com/.../525005  to get control of the device.

    Also try Project 0 from

    http://processors.wiki.ti.com/index.php/LAUNCHXL2-RM57L

    Regarding

    Fernando Guillen said:
    Is this bootcode not present on the device from the factory? These projects need to be built and then downloaded, correct?

    Correct.  Parts are shipped without anything in the Flash.    They can be programmed in system w. JTAG or they can be programmed through a production device programmer from a company like yours.  

    Best Regards,

    Anthony

  • Hi Anthony,

    I attempted to use the project 0 example, but I'm still seeing the error when I change to execute from RAM.

    I've attached the project if you could look into it.

    Regards,

    Fernando Guillen6607.myWorkspace_RM57L_v2.zip

  • Fernando,
    Anthony is correct running with RAM low is the best way to ensure control of the processor while programming with third party tools.

    Here are some tips that you might find helpful for third party programming.

    First swap RAM low, the TRM or provided GEL can tell you how to do this in three simple steps.
    Initialize RAM, this is good to do on all devices but for devices with ECC always on, its required.
    Both of the steps above can be done in a manner that is endianness independent (ie 0x05050505 vs 0x00000005).

    If using TI example code, its designed for customer applications running from Flash.
    First comment out memInit, PBIST, mpuinit and any other functions that when executed will modify the RAM your code is executing from.
    If the device has cache such as the Cortex-R5 (RM57 or TMS570LC) comment out cache_enable as well.

    Update the linker command MEMORY and SECTIONS directive to place code in RAM low (0x0).
    Also update the HL_sys_core.asm lines that declare the stack pointers to absolute values.
    Also update any post-processing tools that are affected by the changes above.

    If your tool prefers a single contiguous image to load use hex470.

    Thank you,
    Forum Support