• State TI Thinks Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 103 subscribers
  • Views 2321 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320C6748 Silicon 2.1 SPI0 Flash invalid opcode

Eric Bernatchez
Prodigy 230 points

Hi TI,

This discussion is related to the following posts :

https://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/112/t/488407

https://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/112/t/489602

I am trying to generate an AIS image (.h) from a .out using AISGen.The .Programis proven tobe functionnal I can run it in debug with a GEL file.

In AISGen I set the PLL0, PLL1, DDR, PSC and PINMUX options. The DSP does not seem to like any of the options. I basically configured all the options based on the GEL file I use to run my program from the JTAG emulator.

The AIS image I generated first starts by setting the PLL0 and clock. The DSP fails as soon as it receives the command 0x5853590D.

My AIS program starts with the following hex code :

0x41504954
0x5853590D 
0x00030006 <- DSP fails after processing this line
0x00180001
0x00000B05
0x00000095
0x5853590D
0x00080003

I used a logic analyser on the SPI lines and the DSP stopps sending the 0x3 command.

I used the debug GEL file as you recommended (http://processors.wiki.ti.com/index.php/OMAP-L1x_Debug_Gel_Files

C674X_0: GEL Output: ---------------------------------------------
C674X_0: GEL Output: | BOOTROM Info |
C674X_0: GEL Output: ---------------------------------------------
C674X_0: GEL Output: ROM ID: d800k008 
C674X_0: GEL Output: Silicon Revision 2.1
C674X_0: GEL Output: Boot pins: 10
C674X_0: GEL Output: Boot Mode: SPI0 Flash
C674X_0: GEL Output: 
ROM Status Code: 0x00000010 
Description:C674X_0: GEL Output: Invalid argument count
C674X_0: GEL Output: 
Program Counter (PC) = 0x80000EC0

I dont understand what can be wrong that wrong with this command. The PLL0 parameters matches what I use in the GEL file and to me its seems to be valid parameters.

I looked at the image examples you refered in my previous post (http://processors.wiki.ti.com/index.php/Boot_Images_for_OMAP-L138

 uses the optionnal configuration (PLL0, PLL1, DDR, PSC or PINMUX).

 

I tried deactivating all the options, the program transfers correctly but does not run at all... Is it possible the Silicon 2.1 has some issue interpreting the optionnal

commands?

 

Here are screen shots of the setting in AISgen  :


please could you help understand why setting any of the optional tabs in AISGen fails with the silicon 2.1 while it works with our silicon 2.0 processor ?

thanks,

Eric

  • 0
    Prodigy 230 points
    Hi,

    I just found out that some of the command in the .h file generated by AISGen are wrong. They dont respect the format described in spraat2f.

    For example, spraatf mentions that the command function should be as is :

    0x5853590D
    ARG COUNT (upper 16bits) & FX NUM (lower 16bits)
    ARG1
    ARG2
    ARGX

    from spraat2f :
    "The first argument specifies the function ID (index of function in the function table) in the lower 16 bits and the number of arguments that the function takes in the upper 16 bits. The number of arguments following the first argument matches the number specified
    in its upper 16 bits."

    In my case the h file generated by AISgen has the following command :
    0x5853590D,
    0x00030006, <- ARG COUNT & FX NUM
    0x00180001, <- ARG 1
    0x00000B05, <- ARG2
    0x00000095, <- ARG3

    The field FX NUM & ARG COUNT is inverted it should be 0x00060003 instead of 0x00030006 . By fixing this manually in my generated .h (perl in my case!) the DSP is happy and does not report the error "Invalid argument count"

    AISGen behavior is as spraat2f but not the DSP silicon V2.1. The DSP Silicon V2.0 was respecting SPRAAT2F.

    What should we do now for the long therm? Update AISGen? Fix Silicon V2.1? or just create a perl script?

    thanks,
    Eric
  • 0 in reply to Eric Bernatchez
    TI__Mastermind 35645 points
    Hi,

    Team is working on this request and will get back to you at the earliest.

    Thanks & regards,
    Sivaraj K
  • 0 in reply to Sivaraj Kuppuraj
    Prodigy 230 points

    Hi

    Do you have any progress?

    Would it be possible to have access to the source code or the logic of the bootloader? that could help us understand what is wrong on the SPI transfer.

    thanks,

    Eric

  • 0 in reply to Eric Bernatchez
    TI__Guru** 116100 points
    Dear Eric,
    Sorry for the delayed response on this post.
    I'm checking with internal team for this issue.

    Please let me know your AISgen tool version (GUI)


    What should we do now for the long therm? Update AISGen? Fix Silicon V2.1? or just create a perl script?

    Not getting AIS invalid issue if AIS perl script used ?
    processors.wiki.ti.com/.../GenAIS
    processors.wiki.ti.com/.../Manually_Patch_AIS_File_using_Perl_Script
  • 0 in reply to Titusrathinaraj Stalin
    Prodigy 230 points

    Hi 

    I am using Version 1.13.

    The output file that we use is theheader file (.h)

    Eric

  • 0 in reply to Eric Bernatchez
    TI__Guru** 116100 points

    DearEric,
    Thanks.
    Sorry for the delayed response.
    Can you please provide your .ais converted and .out file for investigation ?
    We've not forgotten, we are working on this. please also provide the AIS configuration you use.

  • 0 in reply to Titusrathinaraj Stalin
    Prodigy 230 points

    Hello,

    MyProgram.out is the original program.

    The original file we use for our device (silicon 2.0) is myProgram_d800k006.h 

    You will see there is no difference in the file generation between silicon 2.0 and 2.1  (myProgram_d800k006.h  vs myProgram_d800k006.h)

    d800k008.cfg is the AIS config file used to generate myProgram_d800k008.h

    d800k006.cfg is the AIS config file used to generate myProgram_d800k006.h

    As I said we have a dsPIC in SPI slave mode sending all the program to the DSP thats why we use the .h and not the bin file.

    thanks,

    Eric

    toTi.zip

  • 0 in reply to Eric Bernatchez
    TI__Guru** 114410 points
    Eric,

    I am happy to report that this is not an issue with AIS Gen utility.

    We have root caused your issue to an issue in your .cfg file. Since you are using SPI slave mode, you need to configure the bootmode in the .cfg to SPI0Slave instead of SPI0 Flash. you can also change that after loading your configuration in the GUI. Let us know if you still have any issues.

    Please note For the SPI and I2C slave modes, the bootloader operates the SPI/I2C peripheral in 16-bit mode and the boot ROM will not configure the peripheral (SPI) clock in slave mode as the clock is derived from the master.

    Regards,
    Rahul
  • 0 in reply to Rahul Prabhu
    Prodigy 230 points
    Hi Rahul,

    We are not using the SPI Slave bootmode but the SPI-Flash. The dsPIC we are using behaves has a slave SPI flash device. This was working fine on silicon 2.0. Looking at the revision notes of Silicon 2.1 the SPI flash mode did not changes but some of the other bootmodes did. Is it possible this is a regression or maybe that your bootloader does more validation?

    thanks,
    Eric
  • 0 in reply to Eric Bernatchez
    TI__Guru** 114410 points
    Eric,

    We have tested this on several boards with different version of the silicon and can`t reproduce the behavior that you are reporting. If you are using SPI master, I would recommend that you create the image using .bin or .ais rather with .h. The opcodes generated seem to correct and we don`t see this failing when booting from an actual SPI flash devices.

    Regards,
    Rahul
  • 0 in reply to Rahul Prabhu
    Prodigy 230 points

    Hi Rahul,

    After many hours I managed to boot the DSP correctly using the SPI Slave mode.

    The way the data must be packaged on the SPI by the slave changed between silicon 2.0 and silicon 2.1.

    I will soon post more information about it. Something changed between the revisions of the DSP and it does not seem to be documented anywhere...

    Eric