• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Subscribers 99 subscribers
  • Views 1182 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Problem with SYS/BIOS 6 example program.

Zhao Li
Expert 1675 points

Other Parts Discussed in Thread: SYSBIOS, TMS320DM6446

Hi,

I am using CCS V5.1 with a custom DM6446 board. I am trying to run some of the example programs that came with CCS V5.1, such as "task mutex" and "static" examples. The compile was OK with both examples but the program did not give any results (SYSTEM_printf() does not work) when running. It seems that the program got stuck after the BIOS_start() function call and the tasks (either dynamically created or statically created) were not running. The top part of the map file is as follows. Any help or pointers would be greatly appreciated.

Zhao

******************************************************************************
               TMS320C6x Linker PC v7.2.1                     
******************************************************************************
>> Linked Fri Sep 23 17:05:03 2011

OUTPUT FILE NAME:   <sysbios_task_example.out>
ENTRY POINT SYMBOL: "_c_int00"  address: 87605160


MEMORY CONFIGURATION

         name            origin    length      used     unused   attr    fill
----------------------  --------  ---------  --------  --------  ----  --------
  ARM_RAM               10008000   00004000  00002000  00002000  RW 
  IRAM                  11800000   00008000  00000000  00008000  RW X
  L1DSRAM               11f04000   0000c000  00000000  0000c000  RW 
  DDR                   87600000   00800000  0000db90  007f2470  RW X
  DSPLINKMEM            87e00000   00100000  00000000  00100000  RW X
  RESET_VECTOR          87f00000   00000080  00000000  00000080  RW X

  • 0
    TI__Mastermind 32475 points

    What version of SYSBIOS are you using? Can you describe what you mean by stuck?   Where is the program counter?  I think the program is fine...its probably in the Idle Task.

    Is the real question here why the System_printf() didn't print to the console window?

    Judah

  • 0 in reply to judahvang
    Expert 1675 points

    Hi Judah,

    I am using SYSBIOS 6_31_04_27. I meant "stuck" because I did not see any SYSTEM_prontf() out to the console and the program never reached my breakpoints in either task ( the breakpoints are right after the for loop in each task).

    If I suspend the program and view the disassembly, the the PC is at 0x8760dc90 as shown below:

              ti_sysbios_family_c64p_Hwi4:
    8760dc80:   003C34F6            STW.D2T2      B0,*SP--[1]
    8760dc84:   0010A35A            MVK.L2        4,B0
    8760dc88:   003C02F6            STW.D2T2      B0,*+SP[0]
    8760dc8c:   006E402A            MVK.S2        0xffffdc80,B0
    8760dc90:   0043B06A            MVKH.S2       0x87600000,B0
    8760dc94:   00000362            B.S2          B0
    8760dc98:   003C32E6            LDW.D2T2      *++SP[1],B0
    8760dc9c:   00006000            NOP           4

    Does this give you any indication of problems?

    Thanks,

    Zhao

  • 0 in reply to Zhao Li
    TI__Mastermind 32475 points

    Zhao,

    Looks like you are getting a spurious interrupt to Hwi vector 4.  From the code, this definitely looks like its an unplugged vector.

    You need to look at address 0x01800104 in a memory window then look at what value the first 7 bits [bits 0-6] are.  This lets you know what GEM interrupt event was mux'ed into Hwi vector 4.  You should get a number between 0-127.  Then you need to determine what is the source of this GEM interrupt event.

     

    Judah

  • 0 in reply to judahvang
    Expert 1675 points

    Judah,

    The value at that memory location is 0x07060510. What source of interrupt is this? Why i did not get any spurious interrupts when using BIOS 5 to run mailbox example on the same board?

    Can you please give me suggestions on how to avoid spurious interrupts? What document contains info about the interrupt status/control registers?

    Thanks,

    Zhao

  • 0 in reply to Zhao Li
    Expert 1675 points

    Hi Judah,

    FYI. I experimented a few times to see where the code stuck. I got it in Hwi15 three times as shown below.

    Thanks,

    Zhao

              ti_sysbios_family_c64p_Hwi15:
    8760dde0:   003C34F6            STW.D2T2      B0,*SP--[1]
    8760dde4:   003CA35A            MVK.L2        15,B0
    8760dde8:   003C02F6            STW.D2T2      B0,*+SP[0]
    8760ddec:   006EF02A            MVK.S2        0xffffdde0,B0
    8760ddf0:   0043B06A            MVKH.S2       0x87600000,B0
    8760ddf4:   00000362            B.S2          B0
    8760ddf8:   003C32E6            LDW.D2T2      *++SP[1],B0
    8760ddfc:   00006000            NOP           4

     

  • 0 in reply to Zhao Li
    TI__Mastermind 32475 points

    Zhao,

    The value [0x07060510] suggests that GEM event 16 [ARM2DSP0] is mux'ed to Hwi vector 4.  Any ideas what this is the case?  I'm quite sure by default a Hardware reset or SYSBIOS does not map 16  to Hwi vector 4.  See the TMS320DM6446.pdf section 6.7.2 for DSP interrupt mapping.

    Not only was the interrupt mapped, but it was enabled (IER register) somewhere in your code such that when the source triggered the interrupt, the interrupt was taken.

    Judah

  • 0 in reply to judahvang
    Expert 1675 points

    Hi Judah,

    Thanks for your answers. If this belongs to a different forum or discussion group please let me know.

    What is the simple solution to the spurious interrupts? How can i simply disable them by poking some memory locations/registers?

    Thanks,

    Zhao

  • 0 in reply to Zhao Li
    TI__Mastermind 32475 points

    Zhao,

    You need to figure out what the source of those interrupts are coming from.

    Then you also need to find out, why they are being enabled.

    The IER (Interrupt enable register) should allow you to disable interrupts.  When you get to main(), you should be able to manually modify this such that only those interrupts you know are enabled.  This would probably be the easiest way to work around spurious interrupts.

    Judah

  • 0 in reply to judahvang
    Expert 1675 points

    Judah,

    Thanks. My custom board boots up from flash and the DSP code is loaded by the ARM during the ARM startup. The spurious interrupts may come from the DSP code that is loaded and started to run. If I disable the loading of the DSP code, the DSP is held at reset and won't allow me to load code from CCS v5. So i hope i could just access IER on DSP to disable interrupts.

    What is the address of IER on DM6446? I could not find it.

    Thanks for your help.

    Zhao

  • 0 in reply to Zhao Li
    TI__Mastermind 32475 points

    Zhao,

    IER is not memory mapped...Its a CPU register.  Since you are still debugging.  Why don't you put a global variable in main() in your DSP program and spin on it.  Then you can connect the DSP and debug it.

    Judah

  • 0 in reply to judahvang
    Expert 1675 points

    Judah,

    I don't understand what you mean by "spin on it". Can you give an example code?

    Thanks a lot,

    Zhao

  • 0 in reply to Zhao Li
    TI__Mastermind 32475 points

    Zhao,

    Do something like the below.  Then you can connect via CCS without your program jumping out into the weeds and debug this by poking myVariable in a memory window to 1 and allowing the code to continue running.

    Int myVariable = 0;

    main()

    {

        while (!(myVariable))   // spin here - do nothing.  Allows you to connect to the target.

        ... "the rest of your code"

    }

    Judah