• State Resolved
  • Locked Locked
  • Replies 37 replies
  • Answers 2 answers
  • Subscribers 103 subscribers
  • Views 3785 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.

Starterware/TMDSLCDK138: Procedure to Flash and boot the LCDK

Andy Fung
Intellectual 875 points
Part Number: TMDSLCDK138
Other Parts Discussed in Thread: OMAPL138, OMAP-L138, SYSBIOS,

Tool/software: Starterware

Tried to boot the code from flash but failed.

I created an ARM project which simply toggle an GPIO pin high and low. (The project is created from blank. No BIOS, NDK....etc included.) I set the build configuration to Release. Ran it with the debugger. Checked with the Oscope and see the GPIO pin was toggling as expected.

The bootloader project is imported from C:\ti\OMAPL138_StarterWare_1_10_04_01\build\armv5\cgt_ccs\omapl138\lcdkOMAPL138\bootloader

I copied the Entry Point address in the map file of the GPIO ARM project under Release folder, then assign it to "unsigned int entryPoint". Then built the boot.out file.

Move the boot.out file under C:\ti\OMAPL138_StarterWare_1_10_04_01\tools\ais_gen. Got the AIS GEN config file from:

http://processors.wiki.ti.com/index.php/L138/C6748_Development_Kit_(LCDK)#Procedure_to_Flash_and_boot_the_LCDK

Open the AIS GEN and load the config file. Then created boot.ais file and put it under C:\ti\OMAPL138_StarterWare_1_10_04_01\tools\flash_writer

For the ARM project, I built the project and created arm.out file and put it under C:\ti\OMAPL138_StarterWare_1_10_04_01\tools\out2rprc. Then used the out2rprc tool to create arm.bin file and move it under C:\ti\OMAPL138_StarterWare_1_10_04_01\tools\flash_writer.

Switch the SW1 to 0101. Run the command "sfh_OMAP-L138.exe -flash boot.ais arm.bin -targetType OMAPL138_LCDK -flashType NAND -p COM6" and got the following output:

(AIS Parse): Read magic word 0x41504954.

(AIS Parse): Waiting for BOOTME... (power on or reset target now)
(AIS Parse): BOOTME received!
(AIS Parse): Performing Start-Word Sync...
(AIS Parse): Performing Ping Opcode Sync...
(AIS Parse): Processing command 0: 0x58535901.
(AIS Parse): Performing Opcode Sync...
(AIS Parse): Loading section...
(AIS Parse): Loaded 13500-Byte section to address 0x80000000.
(AIS Parse): Processing command 1: 0x58535901.
(AIS Parse): Performing Opcode Sync...
(AIS Parse): Loading section...
(AIS Parse): Loaded 1440-Byte section to address 0x800034BC.
(AIS Parse): Processing command 2: 0x58535906.
(AIS Parse): Performing Opcode Sync...
(AIS Parse): Performing jump and close...
(AIS Parse): AIS complete. Jump to address 0x80000000.
(AIS Parse): Waiting for DONE...
(AIS Parse): Boot completed successfully.

Waiting for SFT on the OMAP-L138...

Flashing UBL boot.ais (23512 bytes) at 0x00000000

100% [ ████████████████████████████████████████████████████████████ ]
Image data transmitted over UART.

100% [ ████████████████████████████████████████████████████████████ ]
UBL programming complete


Flashing application arm.bin (2608 bytes)

100% [ ████████████████████████████████████████████████████████████ ]
Image data transmitted over UART.

100% [ ████████████████████████████████████████████████████████████ ]
Application programming complete


Operation completed successfully.

Switch the SW1 back to 0111 and press reset button on the board. However, not seeing the GPIO toggle. Booting is failed. 

Basically, the steps I wrote above follow the procedures under processors.wiki.ti.com/.../OMAPL138_StarterWare_Booting_And_Flashing

Can you give me some suggestions on this issue? Is there something else I missed?

Thanks,

  • 0
    TI__Mastermind 30365 points
    Moving this thread to the L138 forum.
  • 0
    Guru 26430 points
    Some guesses. I have avoided using the bootloader and sfh utility. In theory, you should not need to set the entryPoint variable in the bootloader code. The entryPoint value is taken from the header that out2rprc puts into the bin file. The bootloader and sfh utility have to agree where app is placed in NAND. Judging from the documentation and code, the bootloader assumes an offset of 6x128KB and the sft assumes block 1. The sfh/sfh code is very obtuse C# code and I can't figure out the size of a NAND block. You might have to compile the bootloader with an IMAGE_OFFSET of 128KB or 64KB.

    If you don't need the bootloader, you can always boot directly into your GPIO app. Process your arm.out though AISGEN as you did with the bootloader producing an arm.bin. Progtam it with sfh:
    sfh_OMAP-L138.exe flash_noubl arm.ais -targetType OMAPL138_LCDK -flashType NAND -p COM6
    Or use the NANDWriter project and program it in using JTAG. A bit slower but not as complicated. The key task of stand-alone execution is that the code in the GEL script has to be moved into either actual code or into the AISGEN config. Usually AISGEN has to get the clocks going and initialize DRAM. If you are executing from L2 or L3 RAM, you can avoid the DRAM part.
  • 0 in reply to Norman Wong
    TI__Guru** 114410 points

    The LCDK NAND is pre-flashed with u-boot so can you please erase the NAND before writing the image to the LCDK board. Instructions to erase the NAND is provided here:

    sfh_OMAP-L138.exe -targetType OMAPL138_LCDK -flashType NAND -p COM6 - erase

    As Norman mentioned, for simple ARM application, you don`t need to provide the entry point as the AISGen tool will parse the binary and locate the entry point. Can you share the AIS configuration that you used to generate the boot image?

    One other way to debug boot issues is to run the debug GEL and check if the ROM bootloader executed correctly.

    Please connect to the ARM/DSP core when the boot fails and run the GEL file (Remove other GEL files before connecting else the system state will be changed). Provide the log here for analysis.

    Regards,

    Rahul 

  • 0 in reply to Rahul Prabhu
    Intellectual 875 points

    8345.LCDK_AISGen_Config.cfg

    Thank you Norman and Rahul. I appreciated your help.

    I can boot ARM project from flash now. I tried to boot DSP project (the sample project ndk_evm6748_elf_helloWorld) follow the same procedures but failed. The only thing different is the entry point address. I put zero for "entryPoint" and put the _c_int00 address I copied from Release .map file to "DspEntryPoint". I attached the AIS config file I used. Please suggest if you have some ideas.

    Thanks,

  • 0 in reply to Rahul Prabhu
    Intellectual 875 points
    I imported another DSP project from C:\ti\OMAPL138_StarterWare_1_10_04_01\build\c674x\cgt_ccs\omapl138\lcdkOMAPL138\gpio and just simply toggle GPIO pin as ARM project. It can be successfully boot from flash. So not sure what is missing for the NDK project. Please advise.

    Thanks,
  • 0 in reply to Andy Fung
    Guru 26430 points
    I acknowledge that the TI Wiki says to change the entry point variables but the code seems to imply that out2rprc will automatically put the entry points into section headers. Can you try with both entry points set to zero? What is the out2rprc command line that you use? What the ARM app in the DSP cases? The bootloader code assume thats the first section is ARM code and the second section is DSP code. Setting the entryPoint to non-zero might cause to code to think the first section to be DSP code. Setting DspEntryPoint to a non-zero is probably okay if you get the right entry point. I would guess that the complicated NDK DSP project uses a different entry point than simple GPIO project. BIOS projects have a lot of auto-magic stuff running before main(). I was under the impression that the StarterWare bootloader was written to bootloader StarterWare projects. I guess loading BIOS projects might be implicitly supported.
  • 0 in reply to Norman Wong
    Intellectual 875 points

    I set entryPoint and DspEntryPoint to zero and booting failed. The out2rprc command I used is: out2rprc helloWorld.out helloWorld.bin

  • 0 in reply to Andy Fung
    Guru 26430 points
    See this Wiki page:
    processors.wiki.ti.com/.../OMAPL138_StarterWare_Booting_And_Flashing
    Booting an ARM+DSP System
    out2rprc.exe [ARM application].out [DSP application].out [application].bin
    Your ARM app would just be an infinite loop. Another thing is that your ARM and DSP app cannot overlap memory unless intentionally shared.
  • 0 in reply to Norman Wong
    Intellectual 875 points
    Thanks Norman.

    Loaded both ARM and DSP. ARM app is just toggling gpio in an infinite loop. DSP is the NDK sample ndk_evm6748_elf_helloWorld.

    I don't think the ARM and DSP app overlapping memory. Here is the memory config copied from both map files:

    =====================================================================================
    OUTPUT FILE NAME: <gpioLed.out>
    ENTRY POINT SYMBOL: "Entry" address: c1080000


    MEMORY CONFIGURATION

    name origin length used unused attr fill
    ---------------------- -------- --------- -------- -------- ---- --------
    DDR_MEM c1080000 02f7ffff 000089f4 02f7760b RWIX

    ======================================================================================
    OUTPUT FILE NAME: <ndk_evm6748_elf_helloWorld.out>
    ENTRY POINT SYMBOL: "_c_int00" address: c6f10940


    MEMORY CONFIGURATION

    name origin length used unused attr fill
    ---------------------- -------- --------- -------- -------- ---- --------
    IROM 11700000 00100000 00000000 00100000 R X
    IRAM 11800000 00040000 00000000 00040000 RW X
    L3_CBA_RAM 80000000 00020000 00000000 00020000 RW X
    DDR c0000000 08000000 06f1f759 010e08a7 RWIX


    After booting, I see gpio toggling but networking does not work. Looks like ARM can successfully booted but not the DSP. Do you have any ideas?

    Thanks,
  • 0 in reply to Rahul Prabhu
    Intellectual 875 points

    gel_info.txt 
    C674X_0: GEL Output: 
---------------------------------------------
C674X_0: GEL Output: |             Device Information            |
C674X_0: GEL Output: ---------------------------------------------
C674X_0: GEL Output: DEV_INFO_00 = 0x1B7D102F
C674X_0: GEL Output: DEV_INFO_01 = 0x00000000
C674X_0: GEL Output: DEV_INFO_02 = 0x00000010
C674X_0: GEL Output: DEV_INFO_03 = 0x00000035
C674X_0: GEL Output: DEV_INFO_04 = 0x00000000
C674X_0: GEL Output: DEV_INFO_05 = 0x000003E0
C674X_0: GEL Output: DEV_INFO_06 = 0x00000080
C674X_0: GEL Output: DEV_INFO_07-DEV_INFO_08-DEV_INFO_09-DEV_INFO_10-DEV_INFO_11-DEV_INFO_12 = 0-0-5629427-6-12-17
C674X_0: GEL Output: DEV_INFO_13,DEV_INFO_14,DEV_INFO_15,DEV_INFO_16 = 5,0,0,4604
C674X_0: GEL Output: -----
C674X_0: GEL Output: DEV_INFO_17 = 0x00030003
C674X_0: GEL Output: DEV_INFO_18 = 0x00000000
C674X_0: GEL Output: DEV_INFO_19 =C674X_0: GEL Output: 0C674X_0: GEL Output: 0C674X_0: GEL Output: 0C674X_0: GEL Output: 0C674X_0: GEL Output: 0C674X_0: GEL Output: 
C674X_0: GEL Output: -----
C674X_0: GEL Output: DEV_INFO_20 = 0x30303864
C674X_0: GEL Output: DEV_INFO_21 = 0x3830306B
C674X_0: GEL Output: DEV_INFO_22 = 0x00000000
C674X_0: GEL Output: DEV_INFO_23 = 0x00000000
C674X_0: GEL Output: -----
C674X_0: GEL Output: DEV_INFO_24 = 0x0601100C
C674X_0: GEL Output: DEV_INFO_25 = 0x0055E5F3
C674X_0: GEL Output: DEV_INFO_06 = 0x00000080
C674X_0: GEL Output: DEV_INFO_26 = 0x23F80005
C674X_0: GEL Output: 

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: 16
C674X_0: GEL Output: Boot Mode: NAND 16
C674X_0: GEL Output: 
ROM Status Code: 0x00000000 
Description:C674X_0: GEL Output: No error
C674X_0: GEL Output: 
Program Counter (PC) = 0xC6EE5140
C674X_0: GEL Output: 
C674X_0: GEL Output: ---------------------------------------------
C674X_0: GEL Output: |              Clock Information             |
C674X_0: GEL Output: ---------------------------------------------
C674X_0: GEL Output: 
C674X_0: GEL Output: PLLs configured to utilize crystal.
C674X_0: GEL Output: ASYNC3 = PLL0_SYSCLK2
C674X_0: GEL Output: 
C674X_0: GEL Output: NOTE:  All clock frequencies in following PLL sections are based
C674X_0: GEL Output: off OSCIN = 24 MHz.  If that value does not match your hardware
C674X_0: GEL Output: you should change the #define in the top of the gel file, save it,
C674X_0: GEL Output: and then reload.
C674X_0: GEL Output: 
C674X_0: GEL Output: ---------------------------------------------
C674X_0: GEL Output: |              PLL0 Information             |
C674X_0: GEL Output: ---------------------------------------------
C674X_0: GEL Output: 
C674X_0: GEL Output: PLL0_SYSCLK1 = 300 MHz
C674X_0: GEL Output: PLL0_SYSCLK2 = 150 MHz
C674X_0: GEL Output: PLL0_SYSCLK3 = 25 MHz
C674X_0: GEL Output: PLL0_SYSCLK4 = 75 MHz
C674X_0: GEL Output: PLL0_SYSCLK5 = 100 MHz
C674X_0: GEL Output: PLL0_SYSCLK6 = 300 MHz
C674X_0: GEL Output: PLL0_SYSCLK7 = 50 MHz
C674X_0: GEL Output: 
C674X_0: GEL Output: ---------------------------------------------
C674X_0: GEL Output: |              PLL1 Information             |
C674X_0: GEL Output: ---------------------------------------------
C674X_0: GEL Output: 
C674X_0: GEL Output: PLL1_SYSCLK1 = 300 MHz
C674X_0: GEL Output: PLL1_SYSCLK2 = 150 MHz
C674X_0: GEL Output: PLL1_SYSCLK3 = 100 MHz
C674X_0: GEL Output: 
C674X_0: GEL Output: ---------------------------------------------
C674X_0: GEL Output: |              PSC0 Information             |
C674X_0: GEL Output: ---------------------------------------------
C674X_0: GEL Output: 
C674X_0: GEL Output: State Decoder:
C674X_0: GEL Output:  0 = SwRstDisable (reset asserted, clock off)
C674X_0: GEL Output:  1 = SyncReset (reset assered, clock on)
C674X_0: GEL Output:  2 = Disable (reset de-asserted, clock off)
C674X_0: GEL Output:  3 = Enable (reset de-asserted, clock on)
C674X_0: GEL Output: >3 = Transition in progress
C674X_0: GEL Output: 
C674X_0: GEL Output: Module 0:	EDMA3CC (0)        STATE = 3
C674X_0: GEL Output: Module 1:	EDMA3 TC0          STATE = 3
C674X_0: GEL Output: Module 2:	EDMA3 TC1          STATE = 3
C674X_0: GEL Output: Module 3:	EMIFA (BR7)        STATE = 3
C674X_0: GEL Output: Module 4:	SPI 0              STATE = 3
C674X_0: GEL Output: Module 5:	MMC/SD 0           STATE = 3
C674X_0: GEL Output: Module 6:	AINTC              STATE = 3
C674X_0: GEL Output: Module 7:	ARM RAM/ROM        STATE = 3
C674X_0: GEL Output: Module 9:	UART 0             STATE = 3
C674X_0: GEL Output: Module 10:	SCR 0 (BR0/1/2/8)  STATE = 3
C674X_0: GEL Output: Module 11:	SCR 1 (BR4)        STATE = 3
C674X_0: GEL Output: Module 12:	SCR 2 (BR3/5/6)    STATE = 3
C674X_0: GEL Output: Module 13:	PRUSS              STATE = 0
C674X_0: GEL Output: Module 14:	ARM                STATE = 3
C674X_0: GEL Output: Module 15:	DSP                STATE = 3
C674X_0: GEL Output: 
C674X_0: GEL Output: ---------------------------------------------
C674X_0: GEL Output: |              PSC1 Information             |
C674X_0: GEL Output: ---------------------------------------------
C674X_0: GEL Output: 
C674X_0: GEL Output: State Decoder:
C674X_0: GEL Output:  0 = SwRstDisable (reset asserted, clock off)
C674X_0: GEL Output:  1 = SyncReset (reset assered, clock on)
C674X_0: GEL Output:  2 = Disable (reset de-asserted, clock off)
C674X_0: GEL Output:  3 = Enable (reset de-asserted, clock on)
C674X_0: GEL Output: >3 = Transition in progress
C674X_0: GEL Output: 
C674X_0: GEL Output: Module 0:	EDMA3CC (1)        STATE = 3
C674X_0: GEL Output: Module 1:	USB0 (2.0)         STATE = 3
C674X_0: GEL Output: Module 2:	USB1 (1.1)         STATE = 3
C674X_0: GEL Output: Module 3:	GPIO               STATE = 3
C674X_0: GEL Output: Module 4:	UHPI               STATE = 3
C674X_0: GEL Output: Module 5:	EMAC               STATE = 3
C674X_0: GEL Output: Module 6:	DDR2 and SCR F3    STATE = 3
C674X_0: GEL Output: Module 7:	MCASP0 + FIFO      STATE = 3
C674X_0: GEL Output: Module 8:	SATA               STATE = 3
C674X_0: GEL Output: Module 9:	VPIF               STATE = 3
C674X_0: GEL Output: Module 10:	SPI 1              STATE = 3
C674X_0: GEL Output: Module 11:	I2C 1              STATE = 3
C674X_0: GEL Output: Module 12:	UART 1             STATE = 3
C674X_0: GEL Output: Module 13:	UART 2             STATE = 3
C674X_0: GEL Output: Module 14:	MCBSP0 + FIFO      STATE = 3
C674X_0: GEL Output: Module 15:	MCBSP1 + FIFO      STATE = 3
C674X_0: GEL Output: Module 16:	LCDC               STATE = 3
C674X_0: GEL Output: Module 17:	eHRPWM (all)       STATE = 3
C674X_0: GEL Output: Module 18:	MMC/SD 1           STATE = 3
C674X_0: GEL Output: Module 19:	UPP                STATE = 3
C674X_0: GEL Output: Module 20:	eCAP (all)         STATE = 3
C674X_0: GEL Output: Module 21:	EDMA3 TC2          STATE = 3
C674X_0: GEL Output: Module 24:	SCR-F0 Br-F0       STATE = 3
C674X_0: GEL Output: Module 25:	SCR-F1 Br-F1       STATE = 3
C674X_0: GEL Output: Module 26:	SCR-F2 Br-F2       STATE = 3
C674X_0: GEL Output: Module 27:	SCR-F6 Br-F3       STATE = 3
C674X_0: GEL Output: Module 28:	SCR-F7 Br-F4       STATE = 3
C674X_0: GEL Output: Module 29:	SCR-F8 Br-F5       STATE = 3
C674X_0: GEL Output: Module 30:	Br-F7 (DDR Contr)  STATE = 3
C674X_0: GEL Output: Module 31:	L3 RAM, SCR-F4, Br-F6 STATE = 3

    LCDK_AISGen_Config3.cfg

    I ran the gel file and copied the information to gel_info.txt. Modified the the config with the AISgen (LCDK_AISGen_Config3.cfg) and generated the ais file and repeat the flash and boot procedure. ARM was booted (gpio toggling) but not DSP (no network connection).

  • 0 in reply to Andy Fung
    Guru 26430 points
    From your map file extracts, I think the ARM and DSP code do overlap.
    Allocated:
    ARM: C1080000 to C3FFFFFF-1
    DSP: C0000000 to C8000000-1
    Used
    ARM: C1080000 to C10889f4-1 entry c1080000
    DSP: C0000000 to C6f1f759-1 entry c6f10940
    It looks like the DSP code does not use L3. You could move your ARM code there. Or into high DDR.
    Another thing is that your AIS config files has "Configure LPSC=False". Usually code will enable power to peripherals so this is probably not a problem.

    Have you run both ARM and DSP code from the emulator?
  • 0 in reply to Norman Wong
    Intellectual 875 points
    Thanks Norman.

    - Moved ARM to higher DDR:

    OUTPUT FILE NAME: <gpioLed.out>
    ENTRY POINT SYMBOL: "Entry" address: c9080000


    MEMORY CONFIGURATION

    name origin length used unused attr fill
    ---------------------- -------- --------- -------- -------- ---- --------
    DDR_MEM c9080000 02f7ffff 000089f4 02f7760b RWIX

    - Set "Configure LPSC=True"

    Same result I got and only gpio toggling but no network connection.

    I ran both ARM and DSP from emulator. The same out file are loaded. Working as expected: gpio toggling and have network connection.
  • 0 in reply to Norman Wong
    Intellectual 875 points
    One thing I noticed that the DSP application entrypoint is not aligned to 1024 bytes. Trying to look for the cmd in the project.
  • 0 in reply to Andy Fung
    Guru 26430 points
    Moving ARM code to high DDR is a good choice. I forgot that the bootloader itself is probably in L3 RAM.

    Not much more that I can suggest. Vaguely remember something about compiling for RAM or ROM. RAM means that the emulator will init data. ROM means code before main() will init data.

    Not helpful right now but maybe later:
    processors.wiki.ti.com/.../Accessing_c_int00
  • 0 in reply to Norman Wong
    Intellectual 875 points
    The problem is the DSP app entrypoint alignment. I modified the cmd file for DSP app. Finally the DSP (NDK) is working from booting now. Thank you so much Norman. I really appreciated you help.

    Thanks again.
  • 0 in reply to Andy Fung
    Guru 26430 points
    Good to hear. I had to read up on that. The ARM sets the DSPs entry point via the HOST1CFG register. That register reserves the lowest 10 bits. Hence the the 1024 byte alignment restriction. The emulator has no such restriction. It just sets the PC directly. Some of the fine print on that Wiki page is mandatory.
  • 0 in reply to Norman Wong
    Intellectual 875 points
    Hello Norman,

    Any ideas and suggestions if I would like to boot the application from SD card? Can you provide some useful link and information?

    Thanks,
  • 0 in reply to Andy Fung
    Guru 26430 points
    I haven't seen many cases of SD Card only boot. Usually boot is from NAND or SPI then SD Card. Usually via u-boot. The ROM Bootloader did not support SD Card till recently and not very well at that. It scans the SD Card for a magic number byte by byte through the first 2MB of the card. It has no idea of file system or files. Creating an SD Card without a file system is not something I ever had to do. No idea how to do so. ISO image maybe? No links I can think of. You might get lucky with TI's WIki.
  • 0 in reply to Norman Wong
    Intellectual 875 points
    Thanks Norman. Found a link
    processors.wiki.ti.com/.../How_to_boot_OMAP-L138_LCDK_from_SD_card

    I believe it talk something about what you have mentioned about the file system of SD card and boot via U-Boot. Supposed I can flash the U-Boot on SD, how about the app code? The instruction does not talk too much about it. And I may need a Linux platform for flashing U-Boot and formatting SD card, am I correct?
  • 0 in reply to Andy Fung
    Guru 26430 points
    You are ahead of me on this one. Looks like u-boot's uflash utility is the bit of magic that gets a binary image into the first sections of a SD card. Technically, the binary image does not have to be u-boot. It can be your own bootloader. The uflash utlity probably requires a Linux host. Doubt it that it has been ported to Windows. Never know though.

    The Starterware Bootloader contains an MMC compile option but it looks suspiciously like for AM335X. So I would have doubts it will compile. That option use CHaN's fatfs code. So if you manage to get the StarterWare Bootloader compiled for SD, your app would be the out2rprc file on the second partition of the SD Card. That partition would be real DOS FAT16 partition.

    If you use u-boot as your bootloader, you have a lot of options. U-boot is quite full featured and it understands DOS file systems and SD cards. You can tell u-boot to load a file from the SD Card into memory at a specific location and jump to it. Possible problem is that it does not understand out2rprc files. You might have to add custom code or use a different format than out2rprc bins. I have never used u-boot for anything except loading linux and u-boot can directly handle linux kernel files.

    If you skip the bootloader entirely, you could package you ARM and DSP apps into one AIS file. Use uflash to program it onto a single partition SD card. Let the ROM bootloader load up both. You will need add DSP wakeup code to your ARM app. Such a strategy would also work with NAND.
  • 0 in reply to Norman Wong
    Intellectual 875 points
    Thanks Norman.

    Sorry about that I should start a new post.

    I found a SD card project (2045.starterware_c6748_mmcsd) from e2e.ti.com/.../1230991

    I would like to access the SD with opening/creating a file and read the content. Can this project do that? I am new on accessing the SD card. Do I need to format the SD before accessing? Can you provide some information on this?

    Thanks,
  • 0 in reply to Andy Fung
    Guru 26430 points
    That thread is my port of the AM335X StarterWare SD Card example to the C6748. That project is functionally limited to what was originally written for the AM335X. It can only read from FAT16 formatted SD Cards. It cannot write or format. That should be okay for the bootloader. Porting the SD Card to the bootloader should be relatively easy since both code use the CHaN FatFs code. Maybe. Possible problem is that the code may not support partitions.

    If you need write/format functionality on the target, others have apparently extended my port to do so. Unfortunately nobody has bothered to post their update.

    You will need to format the SD card from your host. The partition, format, and write instructions on that TI Wiki page should work on a linux host. Windows does not handle multi-partition low-level handling of SD cards. Unless you can find a 3rd party utility. Never had to do it myself. Never looked into. Sorry. No suggestions.
  • 0 in reply to Norman Wong
    Intellectual 875 points

    Thanks Norman. You have mentioned that using the NANDWriter project and program it in using JTAG. Can you provide some instructions or any TI Wiki page? Thanks.

  • 0 in reply to Norman Wong
    Intellectual 875 points
    Ran NANDWriter on emulator successfully. Has been asked to enter the ais file "Enter the binary AIS file name to flash ". So do I need to load two files (boot.ais and app.bin - the application code)? Thanks
  • 0 in reply to Andy Fung
    Guru 26430 points
    Last I looked, NANDWriter accepts just one AIS file. It is not compatible with the StarterWare Bootloader/out2rprc. You can use AISGEN to create one AIS file that contains the both ARM and DSP apps. No bootloader. In the AISGEN GUI, there is a "+" button that allows you to add the second .out (DSP image). The ROM bootloader will load and run the ARM image but it up to your ARM app to start the DSP. The ROM bootloader will load the DSP code into RAM but it will not start it automatically. The StarterWare bootloader has code that you can copy over.

    Otherwise, NANDWriter will need to be modified to support the StarterWare bootloader/out2rprc requirements. You need an unmodified NANDWriter to write the bootloader boot.ais. You'll need a second NANDWriter modified to program the ARM+DSP.bin at the offset that bootloader expects. The ARM+DSP.bin is generated by out2rprc from your ARM.out and DSP.out. Or you could modify NANDWriter to read in offset address for programming.

    In general, the StarterWare Bootloader is not required in most instances. It does not have enough smarts to allow selection of boot images or field upgrading. The only use of the StarterWare bootloader that I can see is for people who boot from one media and switch to another media. Or in some boot modes where the media limits the size of the boot image. Allows bootstrapping to a larger image in the same media.

    I cannot seem to find much about NANDWriter in the TI Wiki. All those flash utilities were bundled with the PSPs. Now the have split out to
    sourceforge.net/.../
    Vaguely remember documentation was buried in PDFs inside the PSP packages.

    If it seems that TI has poorly covered this kind of situation, I think it is because TI is focused on this sequence
    - ROM Bootloader loads u-boot
    - u-boot loads linux
    - linux loads sysbios+syslink app
    The DSP is more of a programmable co-processor to the ARM main processor.
  • 0 in reply to Norman Wong
    Intellectual 875 points

    Thanks Norman.

    I generated the ais file with 2 out files (gpioLed.out and helloWorld.out which I used on StarterWares bootloader) by AISGEN GUI (app.ais). Same AISGEN config I loaded before. Then I ran NANDWriter project (changed the NAND width to 16) on emulator and enter the app.ais when the standard output ask me to so. After it done, I re-cycle the power. I am expected to see the gpio toggling as I did on StarterWares bootloader but nothing output. Do you have any ideas? Thanks.

  • 0 in reply to Andy Fung
    Guru 26430 points
    Assuming
    ARM <= gpioLed.out
    DSP <= helloWorld.out
    I would expect the ARM app to run and the LEDs to flash. The DSP/helloWorld.out would be loaded into memory but would never be run. You have to add code to gpioLed.out to load the entry point and wakeup the DSP.
    It it is the code is swapped between ARM and DSP,
    ARM <= helloWorld.out
    DSP <= gpioLed.out
    then helloWorld would run and gpioLED would not. The ARM side would always need code to wakeup the DSP.
  • 0 in reply to Norman Wong
    Intellectual 875 points
    Thanks Norman. I see the ARM code is running now (gpio is toggling ) but not DSP.

    I copied the following code from bl_platform.c into the main() of ARM project.
    /* write DSP entrypoint */
    HWREG(SOC_SYSCFG_0_REGS + SYSCFG0_HOST1CFG) = 0xc21df800;

    /* power on DSP */
    PSCModuleControl (SOC_PSC_0_REGS, HW_PSC_DSP, PSC_POWERDOMAIN_PD_DSP,
    PSC_MDCTL_NEXT_ENABLE);

    /* release DSP from reset */
    HWREG(SOC_PSC_0_REGS + PSC_MDCTL(15)) |= PSC_MDCTL_LRST;


    However, the DSP is still not running.
  • 0 in reply to Andy Fung
    Intellectual 875 points
    I made a mistake. The ais file was not updated. Now the DSP is working. Thanks again.
  • 0 in reply to Andy Fung
    Guru 26430 points
    Sounds good. You might have to copy over parts of BL_PLATFORM_Config() to the ARM code. That code does start a bunch of clocks. The ARM code will have to prep the system for the DSP. Assuming that the ROM bootloader hasn't prepped the system via AIS commands. You'll have to carefully move GEL script commands from the ARM and DSP project to either AIS config or ARM code or DSP code. Wherever it is appropriate. Try not init the PLL twice though.
  • 0 in reply to Norman Wong
    Intellectual 875 points

    Thanks Norman. Is there any utilities software instead of running CCS project for downloading the code (bin/ais file) via JTAG for production purpose?

  • 0 in reply to Andy Fung
    Intellectual 875 points
    I am using XDS200. Thanks
  • 0 in reply to Andy Fung
    Guru 26430 points
    Sorry, not that I know of. Usually I hand off to the production guys and they have their own tools. Never enquired what they use. I get the impression that they use JTAG for board testing as well as programming, Sometime memory chips are preprogrammed by vendors.
  • 0 in reply to Andy Fung
    TI__Guru** 114410 points
    Andy,

    One option that you can explore for production flashing using JTAG and CCS command line is a tool called loadTI.
    processors.wiki.ti.com/.../Loadti

    Our recommended tool for production flashing however is Serial flashing tool that flashes AIS images using UART.
    processors.wiki.ti.com/.../Serial_Boot_and_Flash_Loading_Utility_for_OMAP-L138

    Regards,
    Rahul
  • 0 in reply to Rahul Prabhu
    Intellectual 875 points
    Thank Rahul.

    I ran the following command with loadti but not able to get loaded:
    loadti -c OMAPL138.ccxml gpioLed.out

    Configuring Debug Server for specified target...
    Done
    TARGET: Texas Instruments XDS2xx USB Debug Probe_0
    Connecting to target...
    testEnv.outFiles: gpioLed.out
    Loading gpioLed.out
    SEVERE: C674X_0: GEL: File: C:\ti\ccsv7\ccs_base\scripting\examples\loadti\gpioLed.out Does not match the target type, not loaded.

    SEVERE: File: C:\ti\ccsv7\ccs_base\scripting\examples\loadti\gpioLed.out
    Does not match the target type, not loaded.
    SEVERE: Error loading "gpioLed.out": File: C:\ti\ccsv7\ccs_base\scripting\examples\loadti\gpioLed.out
    Does not match the target type, not loaded.
    Error code #4011, gpioLed.out load failed!
    Aborting!

    Also, if I need to load ARM+DSP, can I use loadti?
    Thanks
  • 0 in reply to Andy Fung
    TI__Guru** 114410 points
    Andy,

    For questions related to loadTI, it may be best to post on the CCS forums rather than the device forums. I think the Load TI is not optimized to work with multi-core environment so it will try to connect to the core that is assigned CoreID0 which in the OMAPL138 may be assigned to ARM. Is the gpioled.out an ARM binary or DSP?

    Also, see this article, on the loadTI wiki
    processors.wiki.ti.com/.../Loadti

    Regards,
    Rahul
  • 0 in reply to Rahul Prabhu
    Intellectual 875 points
    Thanks Rahul. I created a new post "CCS/TMDSLCDK138: Got the error "Does not match the target type, not loaded." with loadti"

    the gpioLed.out is an ARM project.

    Thanks.