[C6720B] SPI slave boot problems

Thanks, Adriaan!  The key I was missing was sending the LSH of the 32-bit word first.  I can now get through the PING and the next command, and all responses so far are as expected.  It's full speed into the next obstacle...

     Karl

Glad I could help. I'll venture a guess that your next obstacle will be the SET command, which you need to get the PLL configured so you'll be able to up the SPI speed to get your code loaded at a reasonnable speed. I can get it to run at 3MHz.

The trick is that the SET command needs to be followed by 4 parameter words described in the TI documentation, but in the following order:

- type

- address

- data

- wait cycles (sleep)

Good luck.

Adriaan.

Spot on, Adriaan!  The SET command does, indeed, require transfer of the four words to the DSP in an order that differs from the order in which they are written to the AIS file.  Note that the sample implementation (em_protocol.c) in TI's BootUtils folder does NOT alter the order of the words when it sends them to the DSP (the author calls a SET opcode a BOOT_TABLE opcode).  Note also that the sample program was written in the 2002-2004 timeframe.  I'm guessing that the bootloader code got changed and the required updates to the example were never added.

Naturally, the bootloader app note (spraa69c.pdf) makes no mention of this vital information.  I pity the poor sods who had to discover this rearrangement by trial and error.

Thanks for all your help on this effort.  I can now download a full app to the DSP, modify the PLL and EMIF register via an AIS file, and switch SPI clock rates on-the-fly during the app download.

Anything else I should watch out for?

     Karl

Glad I could help.

This booting has been the biggest issue I've run into with the C672x, other than installation issues of CCS.

Just in case you're planning to use the SPI port to talk between ARM and DSP, once the DSP is running: you should use DMA ( dMAX ) for that, and when you do the documentation is wrong on the ESIZE bits in the EVENT13 register: these have to be set to 2 to transfer the 16-bit wide SPI words.

Have fun,

Adriaan.

Adriaan,

Would you mind pointing out where specifically in the documentation the ESIZE is incorrectly defined? If this is the case we want to make sure it gets fixed. According to the dMAX guide depending on what type of transfer you configure will change the effect of ESIZE.

KarlLunt said:

Spot on, Adriaan!  The SET command does, indeed, require transfer of the four words to the DSP in an order that differs from the order in which they are written to the AIS file.  Note that the sample implementation (em_protocol.c) in TI's BootUtils folder does NOT alter the order of the words when it sends them to the DSP (the author calls a SET opcode a BOOT_TABLE opcode).  Note also that the sample program was written in the 2002-2004 timeframe.  I'm guessing that the bootloader code got changed and the required updates to the example were never added.

Naturally, the bootloader app note (spraa69c.pdf) makes no mention of this vital information.  I pity the poor sods who had to discover this rearrangement by trial and error.

Tim,

My mistake. I reviewed the documentation, and found it to be correct. My apologies.

I didn't relalize that the ESIZE enumeration was different for SPI than for General purpose transfers.

Adriaan.

OK, thanks for clearing that up [:)]

Tim or anyone,

I have a problem getting the bootloading to happen fast enough. SysClk 1-3 default to 32, 16, 11 MHz and should become 246, 123, 10 MHz after the SET commands are executed. I have checked SysClk3 (EMIF Clk) and it is not changing after the SET commands.

I can speed up the SPI bus and interword delay after the SET commands, but I still need a 20 usec gap between each word written during the Section_Loads. One other oddity is that I had to put dummy 0xFFFF writes (just as you do after writing opcodes) between the SET parameters or it would hang on the SET opcode (the DSP returned 0x52535253 instead of 0x52535907). I suspect this is not a good thing to do, though; the DSP bootload code is written to respond to dummy writes after receiving an opcode, but probably not after receiving function parameters.

Thanks for any help,

Steve Gallagher

Here is a code snippet (part of my DSP setup) that processes the SET opcode during download.  This code module transfers about 20K bytes to the DSP in under 1/4 second; as part of the transfer, the DSP PLL is upshifted to 60 MHz and the SPI clock is upshifted accordingly.  pAddr points to the next 32-bit value in the DSP app to download.  sw_delay() is a spin-wait delay routine that waits the prescribed amount of time before sending the next word.  The module does not send any 0xffff dummy writes.  pll_configured determines the delay between two 16-bit exchanges with the DSP; if this value is FALSE, the MCU inserts a delay of about 1/2 msec between 16-bit words.  (I bet there's a way to make this block come through as code [fixed-width text] but I can't find it quickly...)

/*
 *  state DSP_PROCESS_OPCODE_SET
 *
 *  This state writes a block of AIS data directly to a memory area of the DSP.
 *  This opcode is usually used to modify registers within the DSP, such as configuring
 *  the PLL and EMIF.
 *
 *  The last value in the 4-word table following a Set opcode is a Sleep value.  This
 *  value is the number of DSP clock cycles to delay before sending any other AIS
 *  commands.  If the DSP's PLL has not been configured, each count in the Sleep
 *  value equals 166 nsecs.  If the DSP's PLL has been configured, each count in
 *  the Sleep value equals 16.6 nsecs (assumes 60 MHz clock). 
 */
            case  DSP_PROCESS_OPCODE_SET:
                SetAddr = *pAddr++;                        // first word after Set opcode is Addr in DSP memory
                SetData = *pAddr++;                        // second word is data value
                SetType = *pAddr++;                        // third word is type descriptor
                SetSleep = *pAddr++;                    // fourth word is sleep count

                ExchangeU32WithDSP(SetType);            // DSP wants type descriptor first...
                ExchangeU32WithDSP(SetAddr);            // then address...
                ExchangeU32WithDSP(SetData);            // then data...
                ExchangeU32WithDSP(SetSleep);            // finally, sleep count

                if (pllConfigured)  sw_delay((SetSleep/10) + 1);    // 60000 counts = 1 msec; argument must be at least one
                else                sw_delay(SetSleep*2);            // 6000 counts = 1 msec
                SETBlockTransferred = TRUE;                // show we have sent at least one Set opcode and data block
                state = DSP_XCHANGE_SYNCWORD;
                break;
           

Karl,

Thanks for your quick response. The only difference I see with your code is that you are using the sleep arg to wait on the MCU side. I didn't think that was necessary since you have to poll on the next opcode anyway. I'll try that and see if it works.

Thanks,

Steve

Karl,

I found my problem. Bad pointer arithmetic accessing the out-of-order parameters. Turns out I was telling the DSP to sleep for a very long time, and that's just what I was seeing.

BTW, I am not delaying on the MCU side and it works fine.

Thanks again,

Steve Gallagher