C6747 and C6743 AIXGen output differences

Thank you Tim.

My only window into the C6747 is the SPI port and the loader.   No JTAG connection, no anything.

Is there a quick and dirty (or clean) sequence of commands I can send through the SPI load interface to get it to read back the register at 0x11700008?  (Or read back any memory read for that matter?)

I'm a little new to the TI DSPs (but long time in embedded systems).  Point me at a document or something to help me sort through the huge amount of TI documents I have.

Thanks.

Rudy,

I do not have any projects I can send to help out with your custom hardware, but I do think this is something which would be fairly simple to find out. Please take a look at the top-side marking of your device and let me know what you see.

TMX320C6747BZKB3

YF-9BA0Y9W

GI

Rudy,

Per the silicon errata this is a Rev 2.0 silicon device which should contain the D800K003 ROM. Please try out the new AISGen utility I linked previously and let me know if you have the same issues.

Sweet.   Thanks again.

It'll take me some time to get the toolchain on my own PC to put together a build using the new AISGen.  Might take until tomorrow.

I will respond with my failure or success.

Thank you Tim.

-Rudy

I have hit an impasse with the newer AISGen tool.

We have our software build running entirely within the Code Composer Studio, which uses the command line version of AISGen, known generically as "hex gen".

The newer AISGen utility comes with a companion hex gen named HexAIS_OMAP-L137.exe, but the newer hex gen has a different format for the command line.  Also, HexAIS_OMAP-L137.exe has no documentation.   It apparently uses some kind of ini file but the format of the ini file is not documented.

Meanwhile, I tried to see if the new AISGen can "create" the ini file, but it seems to not be able to save a configuration file.   Oh, it has menu option where you can "save a configuration in a file", but then it does not actually create/save the file.   (Might be a bug.)

So at the moment I am unable to integrate the new AISGen into our tool chain, and just sustituting the new hex gen does not work because it has an undocumented command line.

Suggestions?

[I'll try a swag at a ".ini" file in the meantime.  So I may have a follow up post on success/failure on that.]

-Rudy

Rudy,

The boot ROM images per revision (D800K00x) are the same between devices.  If you are reading D800K001 for both C6747 and C6743, it means that they have identical boot code.

-Tommy

Tommy or Tim,

I've read in other thread on the forum that a newer version of AISgen for D800K003 is available, version 0.4.0.0 (only 0.1.0.0 can be found on the website).

I have discovered that the 0.1.0.0 version generates bad CRC data in the output file making it unusable for booting the DSP.   I temporarily got around that problem by disregarding the CRC in the file and calculating my own, which did match what the DSP accepted.   However I am still having problems booting the DSP (which has put our product development on hold).

I suspect the newer AISgen could solve my problem.

My TI contacts have gone quiet on me, no answers.

So I'll ask again, is there some way you can get AISgen D800K003 version 0.4.0.0 into my hands?

-Rudy

Rudy,

Can you provide more details on the CRC issue?  This is not an issue we're aware of, so I don't think the 0.4.0.0 version of the tool will help you here. What CRC option were you using, how was the one generated by the tool different from the one you expected, etc? That info should help us to quickly pinpoint the problem and generate a fix.

Regards,

Daniel

I turned on the Section CRC by putting the following line in my OMAP-L137.ini file

crcCheckType=SECTION_CRC

The CRC that the tool generated was wrong - i.e. completely different from the correct CRC.   Recall that we had a download and AISgen working for a C6743 (which is D800K001).  The CRC algorithm has not changed between D800K001 and D800K003.   So I went and wrote my own on-the-fly CRC calculation that matched the output of the D800K001 AISGen and then simply threw away the CRC that the D800K003 AISgen generated so that I could load the C6747.   It worked.

I have also discovered that the example OMAP-L137.ini file we received from the factory had some directives in the wrong order.   It had a section [PLLCONFIG]  which was followed by a section [FASTBOOT], but the FASTBOOT directive blew away all the PLL changes from the PLLCONFIG section.   In the end, I completely removed FASTBOOT because it does nothing.   The boot load happens exactly the same speed with or without it - which is, unfortunately, much slower than the C6743 used to load.   It takes us 10 seconds to load the C6747 but the C6743 loading the same code loaded in under 2 seconds.

Sorry for the plethora of topics in all of this, but it all falls under the umbrella of the subject.

Thank you Daniel.   I tried the newer version of the hex gen utility and it does indeed calculate the correct CRC now.

I tried the [AIS_SeqReadEnable] (and did verify that the0x63 opcode was introduced into the top of the output), but this seems to have no affect on the download speed to the DSP.   I also tried it with [FASTBOOT] (trying it both before and after that command) and it continued to have no affect.

As yet, I have no explanation for why the C6747 takes about 5-6 times longer to download than the C6743.   There was a "fast boot" command 0x13 that no longer seems to be a valid command for the OMAP-L1x7 bootloader (though the AISGen D800K001 does still use it) that the C6747 rejects.  I suspect that is the cause for the slower download.

If you can shed any light on this difference in boot load commands and how "AIS_SeqReadEnable" seems to have no affect, it would be helpful.

Thanks again,

-Rudy

Rudy,

The fastboot was not a documented, supported command.  Are you using the PLL config options to increase the operating speed of the device?  That would be the next thing  I would add if you are not currently doing it.  If you are already using that feature, I'd be interested to know the size of your boot image so we could run our own internal benchmarks.

Regards, Daniel

Yes, I am using the PLL config and I have verified that the  values are being written to the PLL registers.

The AIS output has about 120,400 long words in it, the vast majority of which is data of course.

For the D800K001 hexgen tool, the command line contained the following for initialization the PLL

-pllcfg2 0x0 0x18 0x01 0x02 0x02 0x05 0x1b9

I adapted that into the following for the .ini file for the D800K003 tool.

; This section allows setting the PLL system clock with a
; specified multiplier and divider as shown. The clock source
; can also be chosen for internal or external.
;           |------24|------16|-------8|-------0|
; PLLCFG0:  |    PLLM| POSTDIV| PLLDIV3| PLLDIV5|
; PLLCFG1:  | CLKMODE| PLLDIV7|PLL_LOCK_TIME_CNT|

[PLLCONFIG]
PLLCFG0 = 0x18010202
PLLCFG1 = 0x000501b9

Similarly, the D800K001 hexgen command line has the following for init of external memory.

-emif3c 0x0001C421 0x10912A08 0x70090005 0x000003FA

...which I adapted to the .ini file thus:

[EMIF3SDRAM]
SDCR     = 0x0001c421
SDTIMR   = 0x10912a08
SDTIMR2  = 0x70090005
SDRCR    = 0x000003fa

Does that seem a reasonable adaptation to you?

Perhaps there is a custom modification of SPI register that does the equivalent of what the 0x13 fast boot command did on the D800K001?

For what it is worth, it seems to me that a fraction of the additional time to load the C6747 goes towards time for the 47 to compute CRC.  When I monitor the download of the 43, the DSP is ready with the CRC much faster than the 47.

By the way, the original .ini file I got for the D800K003 had the following at the bottom.

; 0x01C14188 - CFGCHIP3, modified for EMIFB, external memory setup
[AIS_Set]
TYPE    = INT
ADDRESS = 0x01C14188
DATA    = 5
SLEEP   = 0

Is that still recommended?

-Rudy

Rudy,

Not sure why you see such a difference between the two ROM parts.  I can say that some tests we ran last year for secondary boot loaders (where ROM boots a small image which then boots the large application image) we were able to get the C6747 device to copy 1MB of data from SPI flash to SDRAM in approximately 1 second.  That was CPU copies (not EDMA, which could potentially be faster), with the CPU running at 300MHz and the SPI clock running at 50MHz.

If speed is critical, and you can't increase the boot speed through the primary ROM boot loader, then a highly tuned secondary boot loader may be a good idea. The one other thing I can suggest for increasing the ROM boot loader speed is to maximize the SPI clock frequency.

Regards, Daniel

Thanks for the suggestions Daniel.

I was retaining the SPI speed to maintain support of older boards with C6743.  I may venture into trying a higher speed now that I have the PLL init working (recall, only 2 days ago I realized the "FAST_BOOT" thing was resetting my PLL changes back to reset values).

Overnight I recalled one other difference that I ought to toss out.

On our hardware with C6743 our external SDRAM was a single chip, 16-bit side.   For the C6747 we also moved to a double wide memory implementation, 2 chips.

The fact that I can download all our code to the external memory tells me that the memory is working, but it does not tell me that the memory is working "optimally".

Given THAT additional piece of information. do my EMIF register init values for the AISgen still appear correct?

-Rudy

Rudy,

I'm no expert on the EMIF/SDRAM setup, but anytime you change the memory configuration of your system you should definitely go back and re-evaluate your software setup for the EMIF.  I can't guarantee that will change anything with regard to this issue, but it may.

Daniel