• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 100 subscribers
  • Views 2471 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Run an RTSC SWI example on OMAPL138

ROGERG
Mastermind 34670 points
Other Parts Discussed in Thread: OMAPL138

Hi everybody,

at the moment I am trying to get a working standalone version of the RTSC SWI template included in SYS/BIOS 6.30. I am using CCSv4.2.

I made a new project file with the SWI example. When I am debugging the example everything is working as expected.

After generating an AIS .bin file with AISGen tool, I flash the binary to NAND and reboot OMAPL138. When connecting to ARM target I see that the program counter stays in the area where the interrupt vector table is present. The address is 0xFFFF0004 => undefined exception.

After an ARM CPU reset the program counter (PC) changes to an address where _c_int00 is stored. After that a couple of initialization commands for task, clk, semaphore, swi and so on [these threading modules are part of this example] are made. But it seems that the PC does not reach main(). Instead somewhere during initialization an undefined exception occurs and put the PC to 0xFFFF0004 address, where the PC remains in an endless while loop.

AISgen config should be allright (ROM version, DDR2 and PLL config) [same settings which are used in uboot].  I tried different platforms "OMAPL138EVM", "Hawkboard with ROM 1.0", "Hawkboard with ROM 1.1", everytime with the same behaviour.

Can anybody give me some advice or hints what could be responsible for this.

I actually need only an easy SWI example, which works when flashing to NAND, in order to be able to set the ARM CPU in privileged mode for further configuration of SYSCFG registers.

I hope somebody can help me. Thanks and best regards

Gregor

  • 0
    TI__Mastermind 20805 points

    Gregor --

    We have used AISgen to boot and run BIOS apps on an 6748 board, so what you are doing should work.

    Do you know what the Arm is doing at this reset time?   Someone in the OMAP team might have to help with answer that question.  

    The Arm and DSP share the external memory so it's possible that they have a placement conflict (arm and dsp both loading code to same place).

    Here's what I'd do:

    (1)  load the code with CCS

    (2)  use CCS "save memory to file" option and save your .text and .cinit sections to a file -- you can get these base/length addresses in your .map file.

    (3)  make your NAND and reset/load via the NAND boot

    (4)  halt the DSP processor and connect to CCS and repeat step (2).   Then compare the files.

    (5)  If files match, then I'd reset the DSP, and use "load symbols" to load the symbols (not change the memory).  Set entry point to c_int00 and debug.  Sounds like you are already doing this.

    You can modify your DSP memory map using the platform wizard.  Make a new platform with your desired memory map and then point to that.  If your DSP memory needs are modest, you might be able to put everything in the local L2 RAM and disable the L2 cache.  This would avoid memory map conflict with the Arm.

    Regards,
    -Karl-

  • 0 in reply to Karl Wechsler
    TI__Mastermind 34670 points

    Hi Karl,

    thank you for your answer.

    Do you know what the Arm is doing at this reset time?

    1) DSP comes up first doing its ROM Boot Loader => sets itself into idle and calls ARM

    2) ARM starting with its ROM Boot Loader => initializing DDR, PLL; disabling DSP; jump to _c_int00 of ARM code

    But at the moment I do not use DSP, I only use the ARM core. So I would like to run the SWI example on ARM core only. After the jump to exception address 0xFFFF0004 I checked the R14 [ link register] and found out which command causes the undefined exception, which forces the ARM to stay in the "undefined exception handler" => endless while loop. I attached two pics 1. vector table at 0xFFFF0000, 2. command causing the undefined exception [ code has to do with memory init, alloc]

    I am going to try your suggestion and see whether the debugging and flashing code in memory are the same.

    Regards

    Gregor

  • 0 in reply to ROGERG
    TI__Mastermind 20805 points

    Another tool that might prove useful is the disassembly tool (dis470).  If you run dis470 on your .out file you can compare this against the code you see in the dissassembly windows above.   The code at 0xC3000000 above looks funny.  Are you sure that your external memory interface is set up correctly?   The .gel file will do this for you in a CCS environment.  If you are booting from FLASH, then you need to have similar EMIF settings in your FLASH boot sequence.