Unable to flash and boot NDK examples with AisGen and sfh_OMAP-L138 (with C6748 SOM)
TMS320C6748 SOM with d800k002
CCS4, with bios5, bios6, with corresponding versions of ndk, nsp, and bsl
We are able to use AisGen and sfh_OMAP-L138 to convert and load evmc6748_test_led_dip into the SPI flash. The device then boots and runs the application correctly.
We used the same configuration to convert and load ndk_evm6748_bios5_client. The application does not appear to be working, the led's on the rj-45 connector flash on and off every second (orange and yellow), they never go to steady on, and no lease (mac and IP address entry) is found for the device in the DHCP server.
The following screens from AISGen illustrate the procedure we are using.
The "General" tab is shown in two screens to show the DSP application file field. For the LED DIP example, the application file field has two files; ubl_C6748_SPI_MEM.bin (the "@0x80000000" is appended by the AISGen tool), and then evmc6748_test_led_dip.out.
For the NDK example evm6748_bios5_client, the ".out" file is replaced in the field with the ".out" file from the evm6748_bios5_client project. We also tried it without the bin file. The results are decribed above.
The following are the "Peripheral" and "PLL0" tabs.
Hi, can you clarify what you are trying to do?
The LED blink example does not use a UBL, so you would just put the the .out file in the "DSP Application File" field.
For the NDK example, is a UBL required? What setup needs to be done prior to running the program that cannot be done by AISGen? In theory, you would just want the NDK .out alone as the "DSP Application File" and set up the DDR, PLLs, and pinmuxing with AISGen. In other words, when you run from CCS, is there any setup done by a GEL file that you need to make sure happens before running your application?
If you did want to use a UBL to do some configuration before jumping to the NDK example, you would want the ELF .out, not the .bin file. Currently it looks like you are creating an AIS file from another AIS file which is not usually helpful.
Please click the Verify Answer button on this post if it answers your question.----------------------------------------------------------------------------------------------------------
Useful Links:OMAP-L1x/C674x/AM18x Debug GEL File
In reply to jc-ti:
We are trying to load an ".out" file from CCS4 into the SPI flash on a C6748 SOM, and of course, then we want it to boot when the device is turned on.
This worked when did the following:
1) Generate the AIS ".bin" using ubl_C6748_SPI_MEM.bin and evmc6748_test_led_dip.out. (see the screens above for the other AISGen settings).
2) Then load the flash using the following command:
sfh_OMAP-L138.exe -flash_noubl C:\led.bin -targetType C6748 -flashType SPI_MEM
This worked for the LED example only, and only when the UBL was included. When we omit the ubl file in step 1, it does not work. For the NDK examples, it does not work with or without the UBL.
We wonder if what we are missing is -appStartAddr and -appLoadAddr. We did not find documentation that explains how to use them for the C6748 SOM in SPI flash boot mode.
Referring to your second set of questions.
In CCS4 we use the GEL file supplied by the manufacturer (C6748.gel from TMSC3206748_GEL_BSL_Files_v2.3\gel\C6748.gel, see attached).
We have no idea what the settings should be in AISGen to mimic the gel file.
Can you send us a configuration file for AISgen that corresponds to the gel file cited above? Or, can you send us a set of screens?
(The version off AISGen that we have says it is AISgen for D800K006).
Please see the addition to the previous post re the gel fil.
We would like to add some supplemental questions:
Is there a way for AISGen and/or the flasher tools to use the GEL file?
Can the AISGen and flasher tools be integrated into CCSv4?
In reply to Mitch Nelson:
Mitch, I tried this out using the LED flash examples found on this wiki and found a problem when using the C6748 Revision 1.0. Those examples are for OMAP-L138, so with that device, running the LED blink on the DSP requires the ARM to boot first and then wake up the DSP. Since revision 1.0 devices require the KICK registers to be unlocked, and this is done in the ARM program, the DSP program does not do this, so the PINMUX registers do not get set properly for the C6748 SOM.I have updated the source code for the DSP LED Blink program to unlock the KICK registers on the DSP side as well on that wiki. You do not need any UBL to run this blink program. If you have your own LED blink program, make sure the KICK registers are unlocked and that the pinmux registers are actually getting modified; however this example will work on the EVM.Regarding the GEL file, unless you are running any specific functions through the GEL drop down menu, the following functions happen automatically when you connect:
DEVICE_kickUnlock(); // No longer needed for Si Rev 2.0+ PSC_All_On_Full_EVM(); Core_300MHz_mDDR_150MHz();
The kickUnlock should be done in your code like I mentioned earlier.
The PSC's can be enabled by checking the "Configure PSC" box in AISGen. Although the GEL file enables all of them, you can determine which ones actually need to be enabled by looking at your code to see which peripherals are used, or by editing the GEL file and removing lines until your code no longer works.
The PLL and DDR settings are also checkboxes in the AISGen tool. You can look in the GEL file to see what the values are for the multipliers, dividers, and DDR timings.
Alternatively you can copy and paste those GEL functions to the start of your code and leave AIS configurations out of the picture entirely. You can easily test that by making the changes and then removing the GEL file and testing your code. The method used is up to you.
No the AISGen cannot interpret C code like what is in the GEL.
Whether or not they can be integrated would be a question to ask the CCS forum, but I suspect the answer is no.
In other words:
The only thing i actually need to add is the function DEVICE_kickUnlock(); The rest can be set in the AISGen tool with values found in the GEL.
But... It is still suprising that CCS can use the GEL file but it cannot generate an image to load into flash.
I am afraid that your answer does not help us.
!) We are not able to correlate the lines executed in the GEL with the controls available in AISGen.
2) We cannot use the GEL functions as C code in the project, it has dependencies that are not defined in the gel file.
(Note also, that the GEL actually executes five functions on connect, the first to are Clear_Memory_Map(), and Setup_Memory_Map(). )
In other words, it is not possible to execute your instructions.
It is a wonder that TI would not be able to provide a AISGen configuration that does what the GEL does, if that's what it takes to be able to create a bootable image to load into the SOM.
1) Which line specifically are you not able to find a corresponding AISGen file for? See my previous post where I correlated the functions in the GEL to the AISgen check boxes. Again, you only need to enter the parameters required by AISgen, such as the DDR memory type, the timing parameters, and the PLL dividers/multipliers. The actual configuration is done by the bootloader.
2) The GEL file is self-contained and does not have any dependencies. All #defines are at the top of the GEL file, so these may need to be added to your code as well. The GEL file is used for EVM based debug only, so an important part of any project is to put a customized version of these functions in your code (or put them in the AISgen tool). The memory map functions are CCS specific and have no effect on code running stand-alone.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.