c6727 SPI slave boot mode problem

Hello,

There are several Advisories in the C6727B Silicon Errata related to the SPI (slave) peripheral - have you checked into these?

Harbour said:

2. Is there any 16 bit SPI slave boot mode examples available from TI ?
Pdf mentioned has only 32 bit flash examples.

Harbour said:

3. Is there bootloader source code available to help investigate the
problem further ?

There is only one SPI entry in errata for rev1.2 die, that I'm using - 1.2.10 and it is labeled as "final bit hold time" - it is apparently not this issue as all bits are stable readed by the host. As all data remains stable all the time I assume that hardware SPI link is OK.

SPRAA69C does not contain enough information about SPI slave boot mode - no examples, no protocols, no 16 bit mode description, no SPI waveforms (CS pin behaviour for ex.) - this lack of base information is very confusing. PDF must be fixed by describing missed boot mode parts.

As the DSP doesn't boot in SPI slave mode according to SPRAA69C description: two possibilities exists - or the documentation is incomplete or the DSP ROM contains fatal bugs when booting in this mode - so this mode can't be used in this devices at all.

I do not need ROM debugging - if the bootloader source code was available - it will be easier to investigate the problem by looking to the SPI slave mode boot algorithm.

Harbour said:

I do not need ROM debugging - if the bootloader source code was available - it will be easier to investigate the problem by looking to the SPI slave mode boot algorithm.

Thanks, waiting for result as this became a frustrating issue - errata says "do not use SPI master boot mode", so the slave boot mode is the one SPI available, but ...

I've solved this issue - as stated before TI wrote very poor documentation about bootloader for c67 ;(

Anyway I'd like to see 16 bit SPI slave boot protocol from TI support.

Harbour said:

I've solved this issue - as stated before TI wrote very poor documentation about bootloader for c67 ;(

I think that it is time consuming and silly thing to investigate boot protocol of the leading TI DSP with zero documentation and useless support replies. You have to read http://daycounter.com/LabBook/TMS320/C6722_Tutorial.phtml - it is bright example of using your products. At he end of the article you will find solution of the problem. You may recommend this link for your customers ;)

This is a rough article you point out, it points out some deficiencies that do exist for the C672x devices that do cause problems though some have gotten better and some can be avoided; TI still strives to support the devices better. What I really wanted to point out here is that if you want the rev 1.2 silicon he mentions, you should be able to order a TMS320C6727BZDH or TMS320C6727BGDH, the B in the part number indicates the 1.2 silicon revision, if you order the part with the B and you get a older revision than you should have a talk with your distributor (at this point there are probably mostly if not all 1.2 parts in the distribution system anyway). FYI if there is ever a 1.3 silicon released it will probably be TMS320C6727C, the letter after the processor number but before the package letters is usually your silicon revision.

Harbour said:

I think that it is time consuming and silly thing to investigate boot protocol of the leading TI DSP with zero documentation and useless support replies. You have to read http://daycounter.com/LabBook/TMS320/C6722_Tutorial.phtml - it is bright example of using your products. At he end of the article you will find solution of the problem. You may recommend this link for your customers ;)

;) Here in Ukraine the official TI distributor (Scanti) refused even to deliver c67x samples for us, said that we have to buy ordinary chips. The delivery time, after all, for this Ukranian distributor - wiil be 9 months (!) There was no talk about such little thing as silicon revision ;)

 As for SPI slave boot problem - I'm using Weuffen dev kit with 1.2 revision as stated in my second post.

In my first post I've already described my setup - it is the simpliest one - one SPI master (ARM board) connected to one DSP c6727. The SPICLK speed was 1KHz ;)

I've already successfully booted my board, but it tooks me one week playing with zillion setups and investigations against reading some docs or getting qualified tech support ;(

You say - "What the TI may do", this is my own opinion :

- make some cheap c67x devkits and publish their schematic - most people can't start with PADK + CCS - it is very big, complex and expensive. Think about students [ or indians ;) ] - they need some generic CPU (ARM/MSP) + DSP + Codegen

- make some interesting and simple projects for this board

- make public forum for all this

and after this you will have all ready solutions for most tech-support questions plus free advertisement for this platform

I see this strategy - simple, cheap and effective

I am sorry to hear about your distributor, unfortunately I am not very familiar with distribution outside of the US, you do usually have to buy samples for most processors here too, though usually they can be obtained faster.

As to what needs to be done, I think we both agree, having only the PADK and full version of CCS needed for C672x development puts a significant barrier of entry, and that the board should have open schematics so there is some sort of public example schematic (most of our evaluation boards for other product lines are by Spectrum Digital and have publicly available schematics and documentation), I am not sure about having an ARM on the board though, at this point if you are looking for a floating point processor with an ARM you may want to look at the OMAP-L1xx series. There are projects available with the PADK, and good basic BIOS examples within the BIOS install of your CCS, though it is always good to have more. As to the public forum, you are looking at our solution for that :).