• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 99 subscribers
  • Views 168 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

AM625: M4F to run the SDL, RAM not enough

W Z
Expert 2350 points
Part Number: AM625

Tool/software:

256KB SRAM memory system divided into two banks

– 192KB of instruction code (I-RAM)

– 64KB of data space (D-RAM)

Hello TI expert,

We are doing the development of SDL on M4F,  there are some examples provided by TI.

When I integrate three of them, I find that the D-RAM is really not enough for developing with our application software.

I have the concern, does TI have data information about the RAM space needed for all SDL examples?

Or If the D-RAM is not enough for development for SDL, which memory could M4F use?

  • 0
    TI__Mastermind 20306 points

    Hello,

    W Z said:
    Or If the D-RAM is not enough for development for SDL, which memory could M4F use?

    M4F can access DDR. You can use DDR for running SDL if the internal RAM is not sufficient.

    e2e.ti.com/.../faq-sk-am62-how-to-execute-code-from-external-memory-using-m4f-core

    Regards,

    Nihar Potturu. 

  • 0 in reply to Nihar Potturu
    Expert 2350 points

    Yes, we can use DDR, but does TI provide the strategy that which memory sections could put from on-chip RAM of M4F to DDR to achieve better performance, due to put all the sections into DDR will get about 100 times slower.

    From my test, it shows that .text put into DDR will have not too much effect, but if put the stack into DDR, it may quitely slower.

    SECTIONS
    {
    /* This has the M4F entry point and vector table, this MUST be at 0x0 */
    .vectors:{} palign(8) > M4F_VECS

    .text: {} palign(8) > DDR_1 /* This is where code resides */

    .bss: {} palign(8) > DDR_1 /* This is where uninitialized globals go */
    RUN_START(__BSS_START)
    RUN_END(__BSS_END)

    .data: {} palign(8) > DDR_1 /* This is where initialized globals and static go */
    .rodata: {} palign(8) > DDR_1 /* This is where const's go */
    .sysmem: {} palign(8) > DDR_1 /* This is where the malloc heap goes */
    .stack: {} palign(8) > DDR_1 /* This is where the main() stack goes */

    GROUP {
    /* This is the resource table used by linux to know where the IPC "VRINGs" are located */
    .resource_table: {} palign(4096)
    } > DDR_0

    /* Sections needed for C++ projects */
    .ARM.exidx: {} palign(8) > DDR_1 /* Needed for C++ exception handling */
    .init_array: {} palign(8) > DDR_1 /* Contains function pointers called before main */
    .fini_array: {} palign(8) > DDR_1 /* Contains function pointers called after main */
    }

  • 0 in reply to W Z
    TI__Mastermind 20447 points

    Putting the discussion from Yong on email here:

    We may see high risk to deploy all Motor control and SDL on M4F as there is 256KB TCM and DDR access has notable performance degradation.

    Move part of SDL to DM R5 would be a choice, safety OS could be needed on this core. We can deep dive into this and will do follow-up on below actions.

    • Risk analysis for the deployment proposal with Motor control on M4F and FuSa on DMR5 – Nihar, Krithika

    [ans] we don’t recommend to deploy motor control and safety on M4F. please check below consideration and feedback us.

    Motor Control

    Safety Application

    Pros

    Wkup R5F

    MCU M4F

    1. Overall better performance compared to M4, as there are no latency issues accessing DDR from the R5F core.
    2. Fewer software safety diagnostics are needed compared to WKUP R5F.
    Considerations :
    1. Limited memory footprint, with only 256KB of internal RAM available.
    Optimizing SDLs to fit within the internal RAM will require additional effort by the customer.
    2. ECAP, EPWM, and EQEP must be used in polling mode since interrupts are not routed to the WKUP R5 core.

    3. Requires a freeRTOS to run DM.

    Wkup R5F

    Wkup R5F

    1. Overall better performance compared to M4, as there are no latency issues accessing DDR from the R5F core.
    Considerations :
    1. ECAP, EPWM, and EQEP must be used in polling mode since interrupts are not routed to the WKUP R5 core.
    Note: Need to check if the performance observed in polling mode is acceptable to Seyond.
    2. Requires implementation of more software safety diagnostics compared to running SDL on the MCU M4F.
    3. Requires a safety OS such as SafeRTOS or AUTOSAR to run DM+ safety applications.[1]

    MCU M4F

    Wkup R5F

    1. EPWM interrupts are routed to the MCU M4F core
    Considerations:
    1. Limited memory footprint, with only 256KB of internal RAM available.
    2. EQEP and ECAP must still be used in polling mode as interrupts are not routed to the MCU M4F core.
    3. Requires implementation of more software safety diagnostics compared to running SDL on the MCU M4F.
    4. M4F may not meet the required motor control latency.
    5. Requires a safety OS such as SafeRTOS or AUTOSAR to run DM+ safety applications.[1]

    MCU M4F

    MCU M4F

    TI does not recommend this.
    Considerations:
    1. Limited memory footprint, with only 256KB of internal RAM available.
    Even offloading non-performance-critical sections to DDR might not achieve the desired performance.
    2. EQEP and ECAP must still be used in polling mode as interrupts are not routed to the MCU M4F core.
    3. M4F may not meet the required motor control latency.
    4. Safety OS would be required if both Motor Control and Safety applications are run on the M4F core to isolate the safety application from the Motor Control application.[1]

    [1]. FreeRTOS can be modified to make it Safe; this effort will have to be undertaken by the customer and is outside the scope of TI support.