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.

Non-bios-based example of EDMA3 code?

Guru 15580 points
Other Parts Discussed in Thread: OMAP-L138, OMAPL138

Since the EDMA3 LLD for ARM is only supported on Bios 6 (which has been giving me fits), I would like to investigate a non-bios-based approach to coding an EDMA3 application for the ARM in my OMAP-L138 platform. Can anyone suggest some sample code?

Thx,

MikeH

 

  • Mike,

      There are several low level EDMA3 examples in the quickStartOMAPL1x_rCSL package (Version 2). The examples are all based on the various transfer types (Event Triggered, Manual Tigger, and Chaining) There is also a ping-pong buffering example as well.

  • Thanks Drew. Will give it a look.

     

    MikeH

     

  • OK. Here we go again.

    Installation Note: Choosing a installation directory other than the default will require a change in the respective CCSv4 Project Build Properties. It is recommended that you choose the default installation path.

    First of all, what is the default path? Shouldn't it appear on the Wiki page somewhere?

    Upon install, here is what the install wizard says.

    Perfect! This is exactly where I want it! So continue installing........ then compile....ARRRGGGHHHH!

     

    'Building file: C:/Program Files (x86)/Texas Instruments/quickStartOMAPL1x_rCSL/OMAPL1x/support/src/OMAPL1x_common.c'

    'Invoking: Compiler'

    "C:/Program Files (x86)/Texas Instruments/TMS470 Code Generation Tools 4.6.4/bin/cl470" -mv5e -g -O3 --define=OMAPL138 --define=_TMS320C6X --include_path="C:/Program Files (x86)/Texas Instruments/TMS470 Code Generation Tools 4.6.4/include" --include_path="C:/Program Files/Texas Instruments/quickStartOMAPL1x_rCSL/OMAPL1x/support/includes" --diag_warning=225 -me --abi=eabi --code_state=32 --preproc_with_compile --preproc_dependency="OMAPL1x_common.pp"  "C:/Program Files (x86)/Texas Instruments/quickStartOMAPL1x_rCSL/OMAPL1x/support/src/OMAPL1x_common.c"

    "C:/Program Files (x86)/Texas Instruments/quickStartOMAPL1x_rCSL/OMAPL1x/support/src/OMAPL1x_common.c", line 39: fatal error: could not open source file "OMAPL138_common.h"

    1 fatal error detected in the compilation of "C:/Program Files (x86)/Texas Instruments/quickStartOMAPL1x_rCSL/OMAPL1x/support/src/OMAPL1x_common.c".

    Compilation terminated.

    Hmmm...Ok. Let's look at the project's Include Path

    Hmmm...wrong include path in project file....??

    "C:\Program Files\Texas Instruments\quickStartOMAPL1x_rCSL\OMAPL1x\support\includes"

    So how can the installer recommend a default directory ....that is different from what is in the project file????????????????????

    C'mon guys! Get your act together!

    <frustration/overload>

    MikeH

     

     

     

  • ....and now this:

    "${PROJECT_ROOT}/../obj/${ConfigName}/EDMA_ping_pong_armL138.out"

    There is no /obj directory in the project, so no .out file is generated....at least I have not yet found it.....

     

     

  • Mike,

       Ok, so as a quick sanity check, I reinstalled the quickstart package on my computer from scratch to see if I could replicate the errors you have reported in an attempt to figure out what we needed to correct in the install package.

     

      When I did this I didn't get the same errors that you have reported...

     

    .

    MikeH said:
    "C:/Program Files (x86)/Texas Instruments/TMS470 Code Generation Tools 4.6.4/bin/cl470" -mv5e -g -O3 --define=OMAPL138 --define=_TMS320C6X --include_path="C:/Program Files (x86)/Texas Instruments/TMS470 Code Generation Tools 4.6.4/include" --include_path="C:/Program Files/Texas Instruments/quickStartOMAPL1x_rCSL/OMAPL1x/support/includes" --diag_warning=225 -me --abi=eabi --code_state=32 --preproc_with_compile --preproc_dependency="OMAPL1x_common.pp"  "C:/Program Files (x86)/Texas Instruments/quickStartOMAPL1x_rCSL/OMAPL1x/support/src/OMAPL1x_common.c"

     

    From your compiler error message, it seems as through the includes isn't in the specified directory. So I checked on my computer, and sure enought the OMAPL1x_common.c is in the specified path of the include package. On thing I did notice is that for some reason, the default installer location for you has a (x86) after 'C:\Program Files' in the install path.

     

    When I used the package, my install path did not include the (x86) - so there might be an environment variable on your computer that is over powering where the installer is trying to download it.

     

     

    MikeH said:

    "C:\Program Files\Texas Instruments\quickStartOMAPL1x_rCSL\OMAPL1x\support\includes"

    So how can the installer recommend a default directory ....that is different from what is in the project file????????????????????

       It's perfectly legal for the search path of the include (header) files to be different than the root path of the package as long as the CCS has the correct search path specified when it tries to re-compile.

     

     

    Is it possible for you to move the root package to 'C:\Program Files\Texas Instruments' instead of 'C:\Program Files (x86)\Texas Instruments'? and try to import the project again?

  • Drew,

    Drew Abuan said:
    It's perfectly legal for the search path of the include (header) files to be different than the root path of the package as long as the CCS has the correct search path specified when it tries to re-compile.

    You missed my point. My point was that your install wizard suggested a "default installation directory". I assumed that it was correct since your wizard suggested it. So I allowed the wizard to install it there. However, your "example" project has a different include path. The wizard and your project do not match. This stuff should be plug-and-play simple. 

    Drew Abuan said:
    Is it possible for you to move the root package to 'C:\Program Files\Texas Instruments' instead of 'C:\Program Files (x86)\Texas Instruments'? and try to import the project again?

    No. The simpler solution (which I did) is to change the include file paths in the compiler and linker ccs config windows to include the (x86). Now everything works as it should.

    My point is your "samples", "examples", etc. should work out of the box, since most of your "expert" users will not be the ones using them. Screw ups like the one above just causes lots of un-necessary traffic on this forum......

    MikeH

     

  • Mike,

    I hear your frustration and it is certainly valid, and I agree things should be plug-and-play simple.

    As you pointed out, once you changed the project path to include the (x86), which is another way (and yes, one could argue that it is simpler) to solve the path issue, you were able to rebuild the project successfully. The wizard does suggest a default install directory, (C:\Program Files\Texas Instruments\) and it tested to be correct on two different machines I have. 

    Can I explain why the (x86) showed up in the wizard path on your computer? - no I can not -nor am I suggesting that you did anything wrong. I can only show you what it looks like on both of my machines today, one of which I have included below in the screen capture.

    I agree - the samples should work out of the box, which is why we go through the routine of testing the install package on multiple computers to try and mitigate any risk of them not working due to environment variable differences -or- other risks. Unfortunately, we clearly were not able to catch every issue as you have just exposed, so I apologize for not being able to due so. 

    However, now that you have successfully resolved the rebuild issue, I hope you will find the example code as a starting point to set up the EDMA3 to complete transfers without using the EDMA3 Low Level Drivers / BIOS6

     

     

     

     

  • Drew,

    Drew Abuan said:
    Can I explain why the (x86) showed up in the wizard path on your computer?

    Why not? You (TI) should not allow this to happen. You (TI) should be experts at this sort  of thing. As I mentioned in other posts, 90% of the problems occur due to path issues. If TI would adopt a standard framework (beyond what is defined by Eclipse) for *all* products/packages/tools, 90% of the forum traffic would go away.

    On to another question..... Is there a rCSL User Guide? I cannot find one in the Quickstart package, nor do I see one referenced in the "Useful Documents". I have googled for one but nothing comes up.

    MikeH