speex Encoder hangs inside SPEEX_TII_ENC_Lpc_To_Lsp() (CIT_TI_Speex_C55x_20121001bsd)

Hi Dubravko,

We verified this at our end, but not seen any issues. Would it be possible to share the screen snapshots of disassembly and register windows, when it HANGS?

Also, please note that there is an updated version available, which is fully tested.

-Venkat

Venkat good morning,

and thanks for prompt response and investigation on your side !

I will gladly share the snapshots (+disassembly+registers) but the "hang" that I described is not at a single point - in fact the execution never exits the last function, i.e. the PC keeps moving over the (ASM) instructions, but somehow, never encounters exit condition. Let me reproduce it once again, and see how to share/describe the key points. I am thinking that something is missing in my setup, just can not figure what (I am sure your Team did a thorough testing before releasing, and the problem appears so trivial that it must be something simple on my side).

On the updated version - is it publicly available or do I need to place inquiry/PO request from my company to TI directly () ?

thanks & regards,

Dubravko

Venkat good morning,

here are few snapshots that might help:

1 = entry point to the function

2 = register ST0 becomes 0x2800

3 = branch condition (BCC skip_update, TC1) that takes me to skip_update label

4 = branch condition (BCC llc_while, TC1) that takes me back inside lpc_while, and again,

5 = register ST0 becomes 0x2800 again, and steps 3-5 keep repeating (i.e. endless loop or "hang")

thanks & appreciate your advice,

regards,

Dubravko

Hi Dubravko,

I did the same test on the same SPEEX codec release (CIT_TI_Speex_C55x_20121001bsd) you have and I cannot reproduce the problem you had. Here is what I did:

1. Using C5515 EVM with BlackHawk BH-USB-560M.

2. CCS 4.2.4.00033 with CodeGen Tool 4.3.8 and 4.3.9, CCS 5.3 with CodeGen Tool 4.4.1

3. DSP/BIOS version 5.41.10.36 (which cause some issue during the build, because the original version was 5.41.7.24, CCS cannot find std.h)

4. Using Gel file to set the C5515 EVM to use the PLL to 100Mhz (using 32khz RTC clock, JP9 is off)

5. Build the speex_enc (had to build speex first, because the dependency)

6. Load and run the speex_enc.out on C5515 EVM

7. All 334 frames have been encoded.

Can you tell me what is your test environment:

1. What platform you used to run the speex_enc on?

2. What target configuration you have used to run your code?

3. What is your gel file (which is part of the "target configuration") or how do you create your target configuration file?

Best regards,

Ming

Ming good morning/afternoon,

and thanks for detailed investigation on your end !

Here are the three answers:

1 The problem I described above is in simulation. Eventually, the (speex) library and my own Application layer (exericising same API as in TestAppEncoder.c) will run on a custom board, but that is the next step - first I need to make it run in simulation.

2 I created C55xSim.ccxml Target Configuration by selecting:

   C55xx Rev2.x CPU Functional Simulator

"Simulates the C55x Rev2.2 core in a bit accurate (functional) manner, does not model the pipeline effects. Supports a timer and a flat memory system. No other peripherals are modeled. This configuration is faster than the corresponding cycle accurate configuration, suitable for core level algorithm development, but does not provide cycle accuracy."

Also, I am using speex_enc.cmd where I slightly changed three lines just below "DB REMOVED ..." comment:

/* Stack size */
-stack     0x2000    
-sysstack  0x2000  
-heap      0x2000
-lrts55.lib    
 
MEMORY {

PAGE 0:

   MMREGS :     origin = 000000h,   len = 0x00bf
   DARAM0 :     origin = 0000c0h,   len = 0x0040
   DARAM1 :     origin = 000100h,   len = 0x0f00
   DARAM2 :     origin = 001000h,   len = 0xf000

   
   SARAM0 :     origin = 010000h,   len = 0x1e000  
   SARAM1 :     origin = 02e000h,   len = 0x2000  
   SARAM2 :     origin = 030000h,   len = 0x10000    
   SARAM3 :     origin = 040000h,   len = 0x300
   SARAM4 :     origin = 040300h,   len = 0xfd00

   EXT_MEM:     origin = 050000h,   len = 0x1ffff
   EXT_MEM1:    origin = 070000h,   len = 0x1ffff

}


SECTIONS
{
    
    .trcinit: {} > DARAM2  
    .gblinit: {} > DARAM2  
     frt:     {} > DARAM2  
    .cinit:   {} > SARAM4  
    .pinit:   {} > DARAM2  
    .sysinit: {} > DARAM2  
    .bss:     {} > DARAM2     
    .far:     {} > DARAM2  
    .const:   {} > DARAM2  
    .switch:  {} > DARAM2  
    .sysmem:  {} > SARAM2  
    .cio:     {} > DARAM2  
    .MEM$obj: {} > DARAM2  
    .sysheap: {} > DARAM2  
    .stack:   {} > DARAM2     /* size specified above */
    .sysstack {} > DARAM2    /* size specified above */
    .data     {} > DARAM2     /* constants */
    
    .text:    {} > SARAM0
/*  DB REMOVED THESE 3 O LINES ADD COPIED LNES FROM C5515.cmd AT THE END */
/*  speex_enc_channel:{}>SARAM2     Static Memory      */
/*  speex_enc_scratch:{}>DARAM2     Scratch Memory     */
/*  speex_enc_cdp:{}>SARAM1         CDP Scratch Memory */
    speex_tii_enc_channel: {} > SARAM2   /*Static Memory*/
    speex_tii_enc_scratch: {} > DARAM2   /*Scratch Memory*/
    speex_tii_enc_cdp:     {} > SARAM1   /*CDP Scratch Memory*/
    
    .const:SPEEX_Tables : {} SARAM4
    vectors       : {} > SARAM3  
    reset_vector  : {} > SARAM3
    interrupts    : {} > SARAM3
 
}

3 I do not use gel file.

Thank you very much for your analysis and help !

regards,

Dubravko

Ming good morning,

and thanks for recommendation !

Yes, using C55xx Rev3.0 CPU Functional Simulator does solve the issue ! I was able to execute, and got all 334 Frames encoded (as reported by TestAppEncoder). (I wish the option to use Rev2.0 Simulator had not been presented at all).

I'm very happy with your support and all the work you had to do on your side, and especially detailed descriptions/suggestions.

Thanks and regards,

Dubravko

PS

I noticed couple of minor things with this distribution, but I will describe those in a separate thread.