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.

How to debug or what resource to check when DSP/BIOS failed to run?

Hi:

 I use OMAPL137, which contains ARM926 running Linux and C6747 running DSP/BIOS program. The DSP/BIOS program is very simple: It contains main, idle function and two timer function, After init some data in main function, it returns idle function and timer function will toggle LEDs as I expected. 

 I then modify the DSB/BIOS program by insert a "arm clock off" function in the main function, try to turn off the Linux so it will behavior like a single C6747 chip.

The "arm clock off function follows the description  on the page : "section 10.6.2 ARM subsystem clock OFF", SPRUH92, "OMAPL137 Technical Reference Manual". all match the manual, I got ack from Linux. But after the "arm off" function, after main function return, the idle and timer no longer toggle LEDs.

 It seems some resources or registers, timers are abnormal after arm off. Can some one tell me what/how to check to see why DSP/BIOS not working?

  • Hi CalvinTai,

    CalvinTai said:
    But after the "arm off" function, after main function return, the idle and timer no longer toggle LEDs.

    What's going on in the DSP when this happens?  Is BIOS just idling?

    Can you try putting some break points into your idle function and also your timer functions?  Does the break point hit?

    Steve

  • Dear Steve:

      Since it's a custom board, I can't insert break point  and check via CCS/JTAG.

     The DSP program is quite simple and like below pseudo code, If I remark ARM_off() routine, idle, clk1, clk2 all fine, if ARM_off() executed, no LED output & UART output on idle, clk1, clk2:

    main.c:

    static unsigned int r=0,i=0,j=0,delay_cnt1, delay_cnt2;  

    main ()

    {

       UART_put();  // dump data to make sure UART is fine.

       init();

       ARM_off();

      UART_put();  // dump data again  to make sure UART is fine.

       return ;

    }

    // configure via tconf tool

    void idle()

    {

       r++;

       if((r&0xFF)==0)  // make longer delay then output

       UART_put();

    }

    // clk1, clk2 configured via tcf tool, period is 1000 ticks ( = 1ms)

    void clk1()

    {

      delay_cnt1++;

      if((delay_cnt1 & 0xFF) !=0) return;

      i++;

       LED_OUT1 = (i & 0xff);

    }

    void clk2()

    {

      delay_cnt2++;

      if((delay_cnt2&0xFF) !=0) return;

       j++;

    LED_OUT2 = (j & 0xff); 

    }

  • Can you simplify the code in the clk1, clk2 and idle functions?  For example, just turn the led on so that it's always on.  Then you would know if you are reaching these functions even once.

    And to clarify, if you remove the 'ARM_off();' call in main(), then it all works?

    Steve

  • Dear Steve:

     If I remove ARM_off() from main function, it works well, clk1, clk2 will all toggle LED, idle loop can get/put data via UART .

      If I add ARM_off() within main function, clk1, clk2 no longer toggle LED, idle loop didn't get/put dat via UART.

      Now I change clk1, clk2 function to simply output fixed value to LED, and add ARM_off() within main function again, the clk1, clk2 seems OK, they both set LED to the defined data, implies they executed at least once. But idle loop seems never executed. (I check the idle loop by either set LED or output UART data, none successeed).

    The real idle loop codes are as below, do you think the code is right or there is other things need to be checked:

    void idleloop()

    {

       while (1){

         DOUT = 0xA5;

         //UartScan();  // Now remarked, it will scan & output data via uart.

         TSK_yield();

       }

    }

  • This is strange that the idle function isn't running.  Do you have any configuration code in your *.tcf file that's specific to the idle function?  Could you post that?

    CalvinTai said:
    Now I change clk1, clk2 function to simply output fixed value to LED, and add ARM_off() within main function again, the clk1, clk2 seems OK, they both set LED to the defined data, implies they executed at least once. But idle loop seems never executed. (I check the idle loop by either set LED or output UART data, none successeed).

    Can you also try this scenario, but without the ARM_off call (comment out the ARM_off)?  Does the idle function hit if you do that?

    You might want to also post a question to the device forum and ask for some more info about the ARM off instructions that you found in "section 10.6.2 ARM subsystem clock OFF" and if there are any device level implications when the ARM clock is gated.

    Steve

  • Dear Steven:

      The tcf is as below for idle:   

    bios.IDL.create("IDL0_MAIN");
    bios.IDL.instance("IDL0_MAIN").order = 1;
    bios.IDL.instance("IDL0_MAIN").fxn = prog.extern("IDL_mainloop");
    bios.IDL.instance("IDL0_MAIN").calibration = 0;

      The Idle is function is fine when without ARM_OFF.

       Previously I post the question to OMAPL1xx forum. Since the DSP program is load via Linux and DSPLink framework. Maybe the question can't be answered by one only. There is a kind TI guy ask me to seek for help on ARM & DSP/BIOS forum.

       For ARM forum, I hope some Linux exports can help to point out what resource may be influenced when ARM off, Almost at the same time I post to DSP/BIOS forum, I post the question to Linux forum but no response till now. 

       For DSP/BIOS forum, I hope to find out DSP/BIOS start running mechanism & resource usage and see what's the difference using/not using "ARM off".

  • Calvin,

    Were you able to get any good insight on the ARM_OFF functionality from the Linux guys in the ARM forum?

    Steve

  • Hi Steve:

      No response on Linux forum.

  • Calvin,

    It appears that we have exhausted the advice that we can give from the TI-RTOS forum.  I have moved this thread over to the device forum in hopes that someone there can give some additional help with regard to shutting off the ARM subsystem.