• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 384 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.

Original question:

DRV8316REVM: Assistance Needed with DRV8316R and LaunchPadF280025C for BLDC Motor Control

DRV8316REVM: Assistance with BLDC Motor Position Tracking and UART Example Integration

Shahar Cohen
Intellectual 331 points
Part Number: DRV8316REVM
Other Parts Discussed in Thread: TMS320F280025C, LAUNCHXL-F280025C

Tool/software:

Dear TI Team,

I am running a BLDC motor at a very low speed of approximately 0.15 RPM and need to monitor its position over time with a resolution of 1 ms. While attempting to achieve this, I initially explored your graph tool but the resolution is to low so I try a different approach.

Using the Universal Motor Control Lab ,with TMS320F280025C, DRV8316EVMR I have been working to integrate your UART example. However, I encountered memory issues during the merging process (please see the attached image for reference).

Is there an alternative way to allocate memory or manage resources to successfully combine these examples?

Thank you for your support and guidance.

Best regards,

before 



After using uncomment add_device method (file.h)

  • 0
    TI__Mastermind 23666 points

    Hey Shahar,

    I have assigned the thread to a team member. Please expect a response next week.

    Best,
    Akshay

  • 0 in reply to Akshay Rajeev Menon
    TI__Genius 15635 points

    Hi Shahar,

    This doesn't seem to be stemming from the motor or the motor driver and I'm not really familiar with the issue. I'm looping in our MCU team, please give them a couple of days to provide an update.

    Regards,

    Yara

  • 0 in reply to Yara Al Shami
    TI__Genius 11076 points

    Shahar,

    At a glance, the CMD file you are utilizing for this project needs to be adjusted, as this handles memory allocation.

    However, I've only really seen this be necessary when attempting to combine 2 large code bases, not just folding a basic example into a large project. Where does the add_device() function come from? The UMCL does not have this function by default, nor do the SCI/UART examples, if I'm not mistaken.

    Regards,
    Jason Osborn

  • 0 in reply to Jason Osborn
    Intellectual 331 points

    Hey Jason, thanks for your response.

    The UART example I found is sci_ex4_stdout_redirect for the LaunchPad TMS320F280025C, which includes a call to the add_device() function. Each of the three print statements—one to SCIA, one to CCS, and the final one to SCIA—results in a memory error, both when used together and separately. Additionally, I attempted to build a basic list with 20,000 values, which also resulted in a memory failure.

    Thanks,

  • 0 in reply to Shahar Cohen
    TI__Genius 11076 points

    Interesting, I had missed that particular example. Do the other examples (which do not rely on the stdout stream functionality from file.h) work, or do they also result in memory errors?

    Regards,
    Jason Osborn

  • 0 in reply to Jason Osborn
    Intellectual 331 points

    Yes, the other examples also result in memory errors.

    To address these issues, I transitioned to the Sitara AM263x.

    Could you please assist me with this? 

    POST

    Thanks!

  • 0 in reply to Shahar Cohen
    TI__Genius 11076 points

    Shahar,

    I can definitely continue to assist with debugging the LAUNCHXL-F280025C. In regards to the memory errors, I want to note that that's very odd. I've run these examples myself on my own LAUNCHXL-F280025C in the past for testing purposes without issue. Are you using the correct CCXML and CMD files? If so, what are the states of the on-board switches on the LAUNCHXL-F280025C?

    For the Sitara AM263x thread, I'll check on the status of that response.

    Regards,
    Jason Osborn

  • 0 in reply to Jason Osborn
    Intellectual 331 points

    Hi Jason,

    To provide more clarity to the issue, I added very basic logic to the motor lab to implement three modes that control three different speeds, along with a basic PID speed control logic.

    The lab works under this setup. However, when I try to add a UART example / a large array, I encounter a memory error.

    CCXML:


    Driver select:


    Adding array memory error:

    Even when I try to merge the clean universal_motorcontrol_lab_f28002x project with #include <stdio.h> and add a simple method call puts, I still encounter a memory error.

    Thanks

  • 0 in reply to Shahar Cohen
    TI__Genius 11076 points

    I was eventually able to replicate this behavior with the information from your latest post, thank you for your clarifications and particularly for the build log showing the compilation failure. I'll make 2 posts. In the first post (this one), I'll explain a solution to this issue. In the next post, I'll explain the issue and how I decided on this solution:

    The solution:

    • Open .../src_device/f28002x_flash_lib_is.cmd. This is the memory allocation file for the project I mentioned in an earlier post.
      • Lines 57, 70, 75, 80, and 85 all have the text "RAMM1D". This is the project's memory allocation for the .bss, hal_data, user_data, foc_data, and sys_data memory sections.
      • Replace "RAMM1D" with "RAMLS567"
    • Code should now compile without memory errors.

    Regards,
    Jason Osborn

  • +1 in reply to Jason Osborn
    TI__Genius 11076 points

    Now, to explain the issue and how I decided on the solution.

    The problem:

    Since the information related to the streaming process (stdio etc.) is not explicitly allocated with #pragma DATA_SECTION and .cmd file allocation, the compiler performs this process automatically based on the .cmd file. The .cmd file is written in such a way that essentially, the compiler tries to shove all everything into the memory section named "RAMM1D"- the portion of MRAM that this project allocates to data storage. Normally, this isn't much of an issue, but apparently when you try and use the stdio header's functionalities, it causes problems.

    The error view tells us this information, but the text in the build log stating exactly what memory section failed tells us specifically what we need to look for in the memory allocation. To look at this information graphically, use the "Memory Allocation" view in CCS. This view is populated whenever you build a project to show you the memory allocation. (If the view does not seem to be updating when you re-build, click the "pin" button in the top right and click it again. In my experience, this forces a refresh.)

    Here's what failed memory allocation based on the fail state you described looks like:

    Meanwhile, here's what successful memory allocation without any function calls (i.e. before we add any <stdio.h> related functions to the code):

    Note the differences:

    1. .bss (size 458) is only present when the functions are called
    2. .sysmem (size 1024) is only present when the functions are called
    3. .data increases in size from 10 to 248

    All in all, this adds up to a size diff of 1720. Looking at the allocation details of .data, you can see the differences there are related to runtime support for the streaming, as we would expect here.

    Since the RAMM1D (The portion of the MRAM dedicated to data) can only hold up to 1400 and already has 1076 in it before the added functionality, we need to trim it down. The easiest way to do this is re-allocation.

    In the .cmd file I listed, we can see everything that's allocated to RAMM1D. (Just CTRL+F search for RAMM1D and the formatting to look for should become clear starting at the 2nd result.)

    A lot of this can be moved out of MRAM and into LSRAM without facing any issues, in my experience. I chose the sections I did based on my experience with the CMD files of similar projects on this and other devices which allocate differently, as well as how the default CMD file for this device allocates things.

    The new allocation works without issue:

    I hope this helps!

    Regards,
    Jason Osborn