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.

OMAP-L137: Basic example using both cores

Part Number: OMAP-L137
Other Parts Discussed in Thread: TEST

I'm looking for a basic example for the EVMOMAPL137 where both the ARM9 and the C67XX are loaded with a simple "hello world"-like program, i.e. a project where the DSP kicks off the ARM or vice-versa and something simple is carried out. I am not intending to use more OS than necessary, so as bare metal as it can be. Does an example like that exist somewhere in the jungle of TI projects?

//peter

  • Hi,

    I found a legacy software package called quickStartOMAPL1x_rCSL which has an example of ARM2DSP_integration. This example demonstrates a typical implementation of ARM-DSP IPC and I hope it can meet your needs. I attached the installer here together with a simple introduction document. After you install the package, you'll find the example at quickStartOMAPL1x_rCSL\OMAPL1x\rCSL_examples\evmOMAPL137\ARM_examples\syscfg\ARM2DSP_integration_armL137 and quickStartOMAPL1x_rCSL\OMAPL1x\rCSL_examples\evmOMAPL137\DSP_examples\syscfg\ARM2DSP_integration_dspL137. QuickStartOMAPL1xrCSL.pdfquickStartOMAPL1x_rCSL-2.0-Setup.zip

    Hope this is helpful.

    Regards,

    Jianzhong

  • Hi,

    It helps a bit, but as far as I can see it only covers running from a debugger.

    I have a hard time finding up-to-date documentation and/or examples on how to build and run multicore applications e.g. from flash. Up till now I have been using AISgen for generating a binary for the DSP, but I now also need to wake up the ARM9 in order to utilize the full potential of the processor. Can you help me here?

    Regards,

    Peter

  • Hi Peter,

    Have you looked at the Processor-SDK for OMAP-L137? The developer's guide has a chapter on how to generate multicore binaries. Please also refer to this page for OMAP-L137 resources.

    Regards,

    Jianzhong

  • So the usage of AISgen is no longer recommended?

    /peter

  • That's correct. Now we recommend to use everything from the Processor-SDK.

  • I guess I'll have to live with that, although the SDK seems to be far too over-engineered for my purpose ;-)

    Back to my need for an example: is there an example of  OMAP-L137 multicore code for execution on both the ARM9 and the DSP, running stand-alone from spi/flash? I have not been able to locate an example where an entry point for the ARM code is given, but I guess I will have to do something similar to what I do for the DSP?

    Generating the bin files is a secondary issue, I'll get around to that once I have two appropriate .out files.

    /peter

  • Hi Peter,

    You can do the following to generate a multicore application that can run on both ARM and DSP:

    1. create PDK example projects following instructions here. Please make sure you register all SDK components in CCS.

    2. use CCS to build example GPIO_LedBlink_evmOMAPL137_c674xTestProject. The app image that can be flashed into SPI will be generated automatically: pdk_omapl137_1_0_8\packages\MyExampleProjects\GPIO_LedBlink_evmOMAPL137_c674xTestProject\Debug\app.

    3. follow instructions at this link to flash SPI memory with the prebuilt MLO and app generated in #2.

    4. boot your OMAP-L137 EVM from SPI following instructions from the above link.

    5. repeat the same for example GPIO_LedBlink_evmOMAPL137_armTestProject.

    6. if you succeed from #1 to #5, you can move to create multicore app image following instructions here. Basically, the command you need to use is:

    C:\ti\pdk_omapl137_1_0_8\packages\ti\boot\sbl\tools\multicoreImageGen\bin>MulticoreImageGen.exe LE 55 ARM_DSP_app 0 .\GPIO_LedBlink_evmOMAPL137_armTestProject.out.rprc 1 .\GPIO_LedBlink_evmOMAPL137_c674xTestProject.out.rprc

    The two .rprc files will be generated when you build the projects and will be in the Debug folder. The final app is ARM_DSP_app specified in the command above. Use the same method in #3 and #4 to flash this app and boot from SPI.

    If you are successful for all the above, you could add IPC to these two projects following examples in quickStartOMAPL1x_rCSL.

    Hope this is helpful.

    Regards,

    Jianzhong

  • Hi Jianzhong,

    In step 3 you mention a prebuilt MLO. Where is that located?

    Is it possible to build the projects as bare metal? I will not be using the TI_BIOS unless it is strictly necessary to run with both cores.

    Thanks

    Peter

  • Hi Peter,

    The MLO location is given in the documentation page provided in step 3.

    Yes, the projects can build as bare metal by removing symbol USE_BIOS from compiler setting. However, I'd recommend you to build the examples as is first and verify that you can flash and run.

    Regards,

    Jianzhong

  • I have already trues to build without the bios define. It doesn’t link. Tried with the BAREMETAL define as well, also no luck. 

  • Did you get undefined symbol "gpio_test"? If that's the error, please comment out below line in gpio_test.cfg:

    Program.global.echo             = Task.create("&gpio_test", task0Params);
    

    This should make the build work.

  • I did, and if I also comment out the same line in gpio_arm.cfg I can now build without the BIOS define (not that it stops the code from calling OS functions, but that's another matter that I can happily live with).

    The MLO is however a different issue. In step 3 the path is given as <PDK_INSTALL_DIR>/packages/ti/boot/sbl/binary/evmOMAPL137/spi/bin

    , however there is no bin folder in the spi folder in neither 137_1_0_10 nor 137_1_0_11??

  • Sorry, my mistake. I was looking at an older release which had pre-built MLO. Please follow instructions here to build the SBL.

  • Hi Jianzhong

    When moving forward I run into another issue.

    I get a verification error when trying to program the MLO. Single stepping in the debugger I can see that the content of the file is read ok to LOAD_BUFFER_ADDR (0xc0000000), but at READ_BUFFER_ADDR (0xc1000000) there are only FF's. Is it possible that the spi_flashwriter is built with wrong parameters?

    gmake spi_flashwriter_clean SOC=OMAPL137 BOARD=evmOMAPL137 BOOTMODE=spi

    gmake spi_flashwriter SOC=OMAPL137 BOARD=evmOMAPL137 BOOTMODE=spi

    I have verified by using another (older flash writer from TI) that it is possible to program the SPI Flash, so my EVM should be in fine shape.

    /peter

  • I get a verification error when trying to program the MLO. Single stepping in the debugger I can see that the content of the file is read ok to LOAD_BUFFER_ADDR (0xc0000000), but at READ_BUFFER_ADDR (0xc1000000) there are only FF's.

    Sorry, I don't understand your problem. Did you flash the SPI memory according to instructions given here? What did you see in the UART console?

  • I follow the steps you point me to, using the SPI flash writer I built with the instructions given.

    I have one modification on my board, and this is unfortunately that the UART2 TX pin has been lifted so that I can us the SPI CS on the same pin for my application, I therefore don't have output on the UART console. I do however know how to use the debugger, so I step through the code instead.

    If I piece together the printf's in the code the console output would look like this:

    *** PDK SPI Flash Writer ***
    Opening SPI handle...
    SPI handle opened!
    Parsing config file and flashing content to SPI NOR...
    Parsed config line, received parameters: filename = MLO, address = 0x0
    Size of MLO is 0xD348
    Loading binary to memory ...
    Finished loading binary to memory!
    Flashed MLO to offset 0x0!
    Read flash memory at 0x0, checking flashed content...
    Mismatched data at offset 0x0, expected = 0x41504954, read = 0xffffffff

  • Hi Peter,

    OMAPL137 is a 10+ year old device which has under gone several iterations of software offerings and collateral updates. The device does have simple bare-metal examples that we previously released using processors.wiki.ti.com which was shutdown as a channel for collateral distribution.

    I am sharing the PDF version of the wiki for your reference with links to tools that are still downloadable from ti.com. Please walk through the article and let us know if this helps. 

    Boot Images for OMAP-L137_Wiki_PDF.pdf

    OMAPL137-ARM-LED-v1 (3).zip

    Serial Flash tools: https://sourceforge.net/projects/dvflashutils/files/OMAP-L137/ 

    AISGen tools : https://www.ti.com/lit/an/sprab04g/sprab04g.pdf?ts=1620404037544&ref_url=https%253A%252F%252Fwww.google.com%252F 

    Hope this helps.

    Regards,

    Rahul 

  • Hi Rahul,

    I found some useful stuff, and can now flash and run both cores. Basically I use the ARM code in the zip file "as is", and add the DSP code at the start of main to my existing bootable DSP project.

    AISgen is used to combine the two .out files to one AIS file (application = dsp.out arm.out in that order)

    The spiflash_writer_dsp project is used to program the binary into the SPI flash.

    The CSL project mentioned in one of the first replies can be used as inspiration for those who have never made a simple multicore application using shared memory space before :-)

    Thanks!

    Peter

  • Hi Peter,

    Glad that your problem was solved. Thanks for sharing your solution which will benefit other forum users.

    Regards,

    Jianzhong