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.

Linker script required with SYS/BIOS?

Other Parts Discussed in Thread: OMAP-L138

Hi,

I'm starting in the OMAP-L138 world. I'm now trying to create a simple SYS/BIOS project using the Task Example. I'm on CCS5 with the Logic PD OMAP-L138 EVM kit. So far, in all my examples, I needed the "linker_dsp.cmd" script provided by LogicPD to be able to run simple programs on the ARM, or on the DSP. Without the script, I was getting memory errors.

I created the SYS/BIOS task example and forgot to copy the "linker_DSP.cmd" script in the project and to my surprise, the application launched and I saw on the Console:

[ARM9_0] Running task2 function

[ARM9_0] Running task1 function

 

That's it. So, is the linker script kind of embedded in the SYS/BIOS config?? Do I need the linker script at all?

Best regards,

DT

PS: on a side note, I was expecting to see "Calling BIOS_exit from task2" at some point, but never saw it...

  • At least I found out why I don't see "Calling BIOS_exit from task2"...   Clock_getTicks() always return 0. Don't know why. I'm using LogicPD gel files...

  • 1) You shouldn't need the extra linker command script if you're building the example using the evmOMAPL138 platform.

    2) I suspect that the GEL file you're using to connect to the board is not initializing the clocks going to the timers used by SYS/BIOS.

    Try modifying your target configuration to use the attached GEL file for the ARM core and see if things improve.

    Alan

     

    4657.OMAPL138_ARM.gel.zip

     

  • Hi Alan and thanks for answering. 

    I tried your ARM gel file and it works. But I noticed another thing too. For some time, I was getting this error when starting the debug session with the original GEL file:

    ARM9_0: Output: Memory Map Cleared.

    ARM9_0: Output: ---------------------------------------------

    ARM9_0: Output: Memory Map Setup Complete.

    ARM9_0: Output: ---------------------------------------------

    ARM9_0: Output: Enabling Full EVM PSCs...

    ARM9_0: GEL: Error while executing OnTargetConnect(): Attempted to read unmapped virtual memory at 0x01E27800.

    Then, I stopped the debug session, used you GEL and restarted the debug session, I got this:

    ARM9_0: Output: Memory Map Cleared.

    ARM9_0: Output: ---------------------------------------------

    ARM9_0: Output: Memory Map Setup Complete.

    ARM9_0: Output: ---------------------------------------------

    ARM9_0: Output: Enabling Full EVM PSCs...

    ARM9_0: GEL: Error while executing OnTargetConnect(): Attempted to read unmapped virtual memory at 0x01E27800.

    ARM9_0: File Loader: Data verification failed at address 0xC300FC98 Please verify target memory and memory map.

    ARM9_0: Unable to terminate memory download: NULL buffer pointer at 0x320

    ARM9_0: GEL: File: D:\Users\workspace_v5_1\asasas\Debug\asasas.out: a data verification error occurred, file load failed.

    I had to power off and power on again the OMAP-L138 EVM board to make it work. Was my ARM corrupted or something??

     

    Some questions:

    - I compared both my original GEL and the new GEL file you sent me. What is activating the clock?

    - Do you have a modified DSP GEL file too?

    - Where do I find the information about GEL files if I ever want to edit one?

    - For the linker.cmd script, I'm not sure I understand when it's needed or not. It might not be a BIOS question though, but if you have the answer, I'll gladly appreciate it. Is the linker script needed in all projects without SYS/BIOS? The purpose of it is to map the memory?

     

    Best regards,

    DT

     

  • 1) The errors sound like the cache/mmu are still enabled from a previous debug session or testcase.

    You might try adding "disableCaches()" to the "OnTargetConnect( )" function's list of things to do on connect.

    2) It wasn't obvious to me which GEL script lines were actually doing the job. I'd have to dig pretty deep to figure that out.

    3) I've attached our DSP GEL file below.

    4) We downloaded our GEL files from the Logic PD website.

    5) If you're building a RTSC-based example, the linker command scripts are usually generated/provided for you.

    Alan

     

    0675.OMAPL138_DSP.gel.zip

  • Alright, thanks. I was using the GEL files from what came with my OMAP-L138 EVM kit. If you ever find the information, about point 2), let me know :)

    Thanks again,

    DT.

  • Alan,

    back to square one here too. I was investigating the problems I have in those 2 threads:

    http://e2e.ti.com/support/embedded/bios/f/355/t/154290.aspx#558909

    http://e2e.ti.com/support/embedded/bios/f/355/t/154350.aspx#560166

     

    While checking this, I went back to try the Task example mentioned in this thread and it doesn't work. I'm still using your GEL file you gave me here, I haven't changed the code. I have no idea why it still hangs there:

    [ARM9_0] Running task2 function

    [ARM9_0] Running task1 function

     

    And especially, why it worked once like I answered in this thread. What am I doing wrong with the ARM? It's like everything I try on it doesn't work like it must be. I'm kind of stuck because of the 3 threads I have active at the moment, all involving the ARM, which unfortunately is the core I need from the OMAP. Could it be a hardware problem related to the ARM only?

    Sorry for asking a lot of question, I really to sort my problems quickly and I'm new to this OMAP and TI world.

    Regards,

    DT 

  • I found the problem. Actually, I found the answer:

    http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/111915.aspx#396317

     

    My XDS100v2 was updated, my clock was adaptative, but my BOOT mode was not on the EMU Debug choice. All switches were OFF. This made the Task Example work fine. The printing in the console is still really slower when coming from the ARM (the DSP side is really quick, same clocks). But at least it doesn't hang. Hope this time it is the real reason! :)

  • I'm glad you got to the root of this problem. I'll reference your forum posts in the future.

    Alan