Qmss_internaldownloadFirmware problem

Pradeep,

Yes,  this example code for the QMSS infrastructure mode. Please test this code on core0 in the EVM board if you have with you. Did you test other QMSS example code on your designed board for PDSP Firmware? 

Dear Pubesh thanx for your reply.

Same code is running properly on core 0 of TI 6678 EVM.Other QMSS example without PDSP firmeware downlod is working properly in our designed board. But with PDSP firmeware, QMSS example like qmInfraExampleProject,qmSrioContextTestProject etc..

are giving same (not able to download PDSP firmware) problem and program hang at

while (*qmssLObj.qmPdspCmdReg[pdspId]);

rgds,

Pradeep

Pradeep,

The QMSS LLD provides a structure that should be filled with the required information for QMSS initialization parameters. It also downloads the PDSP firmware if a valid firmware image is specified. If the firmware pointer is NULL, LLD will not download the firmware.
Qmss_PdspCfg pdspFirmware[QMSS_MAX_PDSP];

Did you get any error message for PDSP?

Dear Pubesh,

QMSS initialization is same as evm6678, as we are running same example project from

"C:\ti\pdk_C6678_1_0_0_20\packages\ti\drv\exampleProjects\qmInfraExampleProject" ,  on our designed board.

we are loading PDSP firmware image given in example project of PDK6678. firmware pointer is not NULL.

After doing step over debbuging we find that in the following function

static Qmss_Result Qmss_internaldownloadFirmware (Qmss_PdspId pdspId, void *image, uint32_t size)

/* Download the firmware */

for(i = 0; i < count; i++)

qmssLObj.qmPdspIRamReg[pdspId][i] = data[i];

data[i] is  pointing to correct firmware image, but for loop is not updating qmPdspIRamReg which has address of 0x02A61000. I mean data[i] is not getting updated in qmPdspIRamReg in our designed board.

But same project in running in EVM6678,qmPdspIRamReg is getting updated with data[i] (which is pointer to the firmware image).

rgds,

Pradeep

Pradeep,

After discussion with team, It might be two different things that can cause this problem:

1) The PA is not powered up.
2) The PA is powered up, but the PDSPs are already out of reset.

When the PDSPs are out of reset the program memory cannot be read or written.

Dear Pubesh,

We have checked PA is powered up and PDSP is not out of reset.

In code at line

/* Reset the PDSP */

    CSL_FINS (qmssLObj.qmPdspCtrlReg[pdspId]->PDSP_CONTROL_REG, PDSP_PDSP_CONTROL_REG_PDSP_ENABLE, 0);

But still problem is same, qmPdspIRamReg is not getting updated with data[i] (which is pointer to the firmware image).

Pradeep,

The Queue Manager subsystem configuration programmable range is 0x02a6_1000 - 0x02A6_7FFF, this is PROG3(Programmable Range n Registers Reset Values) for MPU2.
Did you compare the QMSS PDSP regsiter values with EVM, which is working.
I am checking with team and will let you know.

Next thing i'd do is a stop-watch clock check.  Build a program which sets up TSCL. 

#include <c6x.h>

void main()

{

   TSCL = 1;

   while(1) asm(" nop");

}

This activates a cycle counter in TSCH+TSCL in the c66.  Put TSCH+TSCL in a expressions window of CCS.Using a stopwatch or a clock that shows seconds use the following procedure to check your clock:

load and run the program.

stop it.

put tsch and tscl into watch/expression window.  You should see nonzero value in TSCL and possibly TSCH (depending on how long you let it run before stopping).  Record these values.

start manual timing (for example watch second hand cross the :30 mark).  As it crosses start running the program.

wait 120 seconds.  As second hand crosses the same mark, stop the program.

Record TSCH/TCSL. 

Treat TSCH:TSCL as a 64 bit number, subtract.  This is number of cycles in 120 +/- 0.2s.  This will tell you the clock frequency within 0.2%.  If you didn't program the PLL it shoudl be the same as your input clock frequency.  If you program the PLL, it should be your expected frequency (around 1GHZ).

If this is way off (a multiple instead of a small %) your expected frequency, fix your clocking.  Even if you used a scope on a pin, I still suggest using a stopwatch, because it lets you check the frequency from the DSP's point of view, not from a pin's point of view.

will still follow up with how to check status of PDSP.

To check the first PDSP, look at 0x02a6e000 and 0x02a6e004 in a memory window.

Prior to download (Qmss_init) should contain 0x00000001 and 0x00000000.

After download, 0x02a6e000 should contain 0x00008003 and 0x02a6e004 should contain a small (<0x400) "random" number which is the program counter inside the PDSP.   By refreshing a few times, you should see the 0x02a6e004 location changing "randomly".

Please follow up with your observations of 0x02a6e000/4 before and after download compared to mine especially if you don't see 0x8003 after download.

Dear John Dowdal,

As per your post we have kept PLL in  bypass mode by resetting the device (system reset from ccs), and immediately ran the example,But still problem is same, qmPdspIRamReg is not getting updated with data[i] (which is pointer to the firmware image).

with regards,

Pradeep

Dear John Dowdal,

We have done stop-watch clock check as suggested by you. After loading and running this following programme :

#include <c6x.h>

void main()

{

   TSCL = 1;

   while(1) asm(" nop");

}

we have checked tsch and tscl into watch/expression window:

TSCL:0xc70503ca

TSCh:0x00000000

After this we have used stop watch and ran program for 120 second here is values of

TSCL:0xaf439397

TSCH:0x0000001c

total number of clock cycle is 119860531149(0x1caf439397-0xc70503ca).

Our DSP is running at 1GHZ,hence the clock period is 1 nsec. In 120 second time clock cycle should be 120000000000, so PLL setting is proper.

With Regards,

Pradeep

Dear John Dowdal,

As per your post  we have checked these PDSP registers  0x02a6e000 and 0x02a6e004 in a memory window:

Prior to download (Qmss_init), the registers value of PDSP( 0x02a6e000 and 0x02a6e004) are 0x00000001 and 0x00000000.

After download, 0x02a6e000 contain 0x00008003 and 0x02a6e004 contains 0x0000ed29,which is more than 0x400.

By refreshing a few times, the values at  0x02a6e004 location changing randomly(values are 0xa0d1,0xced6,0x93bb,..).

 The value at 0x02a6e004 location is more than 0x400, what could be the reason behind this.(and qmPdspIRamReg is not getting updated with data[i] (which is pointer to the firmware image)).

Regards,

Pradeep

Dear Pubesh,

We have compared the QMSS PDSP registers with EVM, here is the comparision:

Prior to download (Qmss_init)

PDSP Registers                                                            EVM6678                                        Our Custome Board 6678

Control Register (0x02a6e000):                                0x00000001                                         0x00000001

Status Register (0x02a6e004):                                  0x00000000                                         0x00000000

Cycle Count Register (0x02a6e00c) :                         0x00000000                                         0x00000000 

Stall Count Register (0x02a6e010) :                           0x00000000                                         0x00000000

Command Register(0x02ab8000):                            0x615a001c                                           0xFFFFFFFF

After download (Qmss_init)

PDSP Registers                                                            EVM6678                                        Our Custome Board 6678

Control Register (0x02a6e000):                                0x00008003                                         0x00008003

Status Register (0x02a6e004):                                  0x0000000e                                         0x0000ed29

Cycle Count Register (0x02a6e00c) :                         0x00000000                                         0x00000000

Stall Count Register (0x02a6e010) :                           0x00000000                                         0x00000000

Command Register(0x02ab8000):                            0x00000000                                           0xFFFFFFFF

We have highlighted  the differences between PDSP registers of  EVM and our custom board. What could cause these differences?

Regards,

Pradeep 

The stop watch exercise was done with the PLL *not* in bypass, correct? 

In Qmss_internaldownlaodFirmware() inside the data copy loop, you should be able to see the download work word by word via 0x2a60000.  It should match data[i].  ONce the control registers are written at the bottom of Qmss_internaldownloadFirmware(), the program memory becomes "locked" and you can't read it any more.  If you want to single step Qmss_internadownloadFirmware, just add qmss_drv.c to the qmInfraExampleProject (and add include path ti/drv/qmss so it can find qmss_osal.h).  Depending when you are looking (before or after control reg write), it might or might not matter that you can read the program data back.

The "status register" shows the the PDSP doesn't work because its internal program counter is in the weeds.

Was the exact same binary run on both the EVM and your board to collect results?  If the exact same binary that only uses internal memory (not DDR) is run on both boards, and gets different results for QMSS (which is always on), then it generally implies that something is wrong with the setup such as power on reset sequence, clocking, voltages, temperature/cooling.  If its different binaries compiled with different flags or build process, then it implies that something is unexpectedly different in the two images resulting in failure to download.

Dear John Dowdal,

Yes stop watch exercise was done with the PLL. We included qmss_drv.c for single step. Binary file is same for both EVM and custome board and uses internal memory.Again we are checking clocking and voltages.But all other things is working fine except loading PDSP firmware.

Regards,

Pradeep 

Since same binary behaves differently on two boards, and the pdsp download code has been around a long time (several years) without issues, makes the board suspicious.  It seems that the program memory for the PDSP isn't stable given your observations.  I presume that you have tried more than one board and/or if your board has multiple devices, multiple devices on the same board, and all boards/devices show the same symptom?