Rebuilding serial flash utility

Hi:

The simple way is checking the makefile in each utility, for example, if you want to rebuild sfh utility, you will find the related makefile in .\gnu\sfh\makefile.

Inside the makefile, you will find following files be used to build the tool:

REMOTESOURCES=$(PROGRAM)_ais.cs AIS.cs AISParse.cs device_name.cs Debug.cs CRC.cs EmbeddedFileIO.cs FileIO.cs SerialIO.cs ConsoleUtility.cs

Just copy these .cs files list above to new directory where you want to rebuild it.

Remember some resources may need to join into project also.  For example if you want to re-build sft, not only include cs files, you should add sft_xxx_xxx.out depending on which out file you want to put into TI's DSP (or simply add all the possible files into the project).

 

 

Hi,

It seems that you do not have cl6x compiler. Or it is not in the PATH of you Cygwin.

make[3]: cl6x: Command not found

rgds,

kc Wog

Hi kc,

 

"It seems that you do not have cl6x compiler. Or it is not in the PATH of you Cygwin.

make[3]: cl6x: Command not found  "

 

i have cl6x.exe file in the code generation tools folder of Texas Instruments setup  How do I set it or even check whether its in my Cygwin path or not ??

I have the location of bin folder for the code generation tool(including cl6x.exe ) added to the environmental variable of windows 

Thanks for responding !!

kc,

 

I  have added "C:\Program Files (x86)\Texas Instruments\ccsv4\tools\compiler\C6000 Code Generation Tools 7.0.5\lib" and "C:\Program Files (x86)\Texas Instruments\ccsv4\tools\compiler\C6000 Code Generation Tools 7.0.5\bin "

 it doesnt show any such errors as cl6x:command not found ( i added these to the environmental variables of PC windows) and these two show up when i type printenv PATH in cygwin

But still it gives an error for rts64plus.lib not found which sounds goofy as I can see the path for lib (mentioned above) present in PATH variable

 

 

Also my question for Calvin 

 

I have copied those files mentioned in the make file to the sfh folder and still I dont understand that whether all .cs file, modules , .c files (for OMAP) are all one project ?? 

Are all these to be formed as a CCS project or not 

 

 

 

I have a custom board which has 25Mhz clock input instead of 24 Mhz on EVM and( with UART said to be working fine with 4-5% error in timing )should I still expect BOOT ME message on power on in uart boot mode same as EVM 

 

 

 

 

 Hi,

NIKHIL RAJPAL67586 said:

But still it gives an error for rts64plus.lib not found which sounds goofy as I can see the path for lib (mentioned above) present in PATH variable

 

 I do have the same problem. Basically we need to let the compiler know the directory for the library search. For cl6x, there is a below option to do that. Just need to find out the proper place in makefile to add this in.

  -i=dir               Add <dir> to library search path

NIKHIL RAJPAL67586 said:

I have a custom board which has 25Mhz clock input instead of 24 Mhz on EVM and( with UART said to be working fine with 4-5% error in timing )should I still expect BOOT ME message on power on in uart boot mode same as EVM 

 

 With a 25MHz clock, I think you should use this 25/2/13/8=120192 baud rate according to the below post.

http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/127373/459068.aspx#459068

rgds,

kc Wong

Hi:

The compiling flow suggested by TI is for one who is familiar with cygwin, not for one who want to join TI group (just joking, why they don't suggest easier way to build the tools, I will mention later).  You may take much time building the environment and fail to work  if your are not lucky. And the cygwin environment is only for building flash tools......

I suggest to use cygwin only when TI (and you) have no choice.

For all the target side tool projects all can be easily opened by CCS3.3 (suggest  to use since those projects are originally built by CCS3.3) or CCS4.x (I built on CCS4.x, they should be imported, a little tedious procedure) and it's very easy to compile  successfully, just click "build" from menu item. Forget the path setting problem, which is already solved when you installed CCS.

For host side projects, they are create by C#. C# comes from Microsoft, it's much easier to use Visual studio to build C# project, you can modify and debug very easily inside the Visual studio.

Visual studio express can be download freely from Microsoft's (suggest VS2008 instead of VS2010 if your computer is not fast). If your don't know how to create and add C# to a project, just learn from the tutorial, I think it takes 1 or 2 hours for you to learn.

kc , 

 

 

Thanks for responding I have got that build a bit different way though "copying the required library file to project folders"  .I was also missing the path of the .NET framework in my windows . I will still look for what u mention to change in makefile 

I will try with that baudrate thanks for the link

 

I still have a problem 

When I use the v1.00 from the sourceforge it works fine and shows me progress bars and loading all three dspubl, ubl for arm and u-boot i can see the u-boot messages of the uart terminal but when i use other versions(i have tried v2.11 v2.15 v2.20) even the pre-built sfh_OMAP-L137.exe have some issues 

"They do show progress bars and show that flashing completed for all three but I cannot see any u-boot messages on the uart "  I wanted to use latest of those as I want to modify the code for different spi and uart port 

Have you used any of those??  as I just tried out v2.15 ,v2.20 , v2.11 all pre-built files and even tried out rebuilding the v2.20 and flashing through new build but all of them show the progress bars completing and even the successfull message but doesnt seem to be working as v1.00 loading same binary files 

 

If you can share your experience with different versions and suggestion for a way to stepwise debug this project welcomed !!

 

Thanks

NIKHIL RAJPAL 

 

Hi,

I did not try all these versions.

By the way, not sure you have looked at the below url before. It says that UBLs from different PSP releases should use different version of serial flasher. Not sure this could be your issue or not.

http://processors.wiki.ti.com/index.php/Serial_Boot_and_Flash_Loading_Utility_for_OMAP-L138

And the last section, there is a section for suggestion about "Modifications for Custom Boards". Hopefully it helps.

Calvin is right. It is much easier to use CCS to build. Good luck.

rgds,

kc Wong

Hi Calvin 

I have tried importing those projects in CCSV4 . I have done that earlier for spiflashwriter which writes on flash using jtag 

but when I import projects like UBL_SPI_MEM present in OMAP-L137\CCS\UBL_ARM it doesnt automatically include the source or include folders but instead gives a migration log saying "!ERROR: Unknown device 'TMS320C64xx'!"

I didnt had any such problem importing either for the SPI_Flashwriter project or example codes for the evm from Spectrum digital which were all ccsv3.3. So do I need to form projects by myself by identifying what files are for which project ??

 

For C# projects I would look for .sln file in Visual studio . Or do I need to form new projects and include the files . I have never handled c# code but used Visual Studio for c projects so I will try out to form c# projects if that is needed . I would rather expect to have .sln or csproj files if Visual studio is to be used for those projects but I dont find any of those .

thanks for responding 

 

 

kc ,

 

I have looked at the section suggesting "Modifications fir Custom Boards " .I have probably identfied modifications i need to make with help of that section but I am stuck at earlier stage as 

 

I am not able to get a new built or a prebuilt available sfh_OMAP-L137.exe to run on evm and give u-boot messages ( strange that these prebuilt .exe files show that the binaries have been loaded but dont show any u-boot messages ) apart from v1.00 for which source code is not provided but using that I am able to get the binaries loaded and see u-boot messages 

If its easier to build through CCS I would be glad if u know any link for how to do that considering the problem i mentioned in importing the projects to CCSV4

May be the point you mentioned that UBLs from different PSP releases should use different version of serial flasher is  the problem. I will ponder into that 

I had one more question

Is it that this serial flasher first loads some kind of flash writing code in RAM which intakes the ubls  in binary format over uart ??

 

Thanks 

NIKHIL RAJPAL

_Hi,

_{I found another url that shows how to set the environment variable for library search path. I tried that, and now my build works fine.}

http://processors.wiki.ti.com/index.php/Rebuilding_the_Flash_and_Boot_Utils_Package

C6x Compiler Tools

• These are available free of charge: https://www-a.ti.com/downloads/sds_support/TICodegenerationTools/download.htm
• After installing, add the following Windows environment variable: C6x_C_DIR = <Path to lib directory of Code Gen tools, i.e. C:\Program Files\Texas Instruments\C6000 Code Generation Tools 6.1.11\lib>
• Add the bin directory of the TI C6000 Code generation tools to the system path environment variable (i.e. "C:\Program Files\Texas Instruments\C6000 Code Generation Tools 6.1.11\bin")

_rgds,

_{kc Wong}

NIKHIL RAJPAL67586 said:

Is it that this serial flasher first loads some kind of flash writing code in RAM which intakes the ubls  in binary format over uart ??

Below is my understanding. You put the device in UART boot mode. There is a flash writer embedded in the serial flasher. This flash writer will then be loaded into ARM internal RAM and run from there. Depending on your flash type, different flash writer will be loaded.

Then the flash writer will first get the UBL and write to flash, and follow with u-boot and write to the flash.

And there is an option for you to set different baudrate as well since you have 25MHz clock (provided your host support non-standard baudrate).

rgds,

kc Wong

$ ./sfh_OMAP-L138.exe
-----------------------------------------------------
   TI Serial Flasher Host Program for OMAP-L138
   (C) 2010, Texas Instruments, Inc.
   Ver. 1.67
-----------------------------------------------------

Usage:

sfh_OMAP-L138 <Command> [-targetType <Target>] [-flashType <FlashType>] [<Options>] [<InputFiles]
        <Command> is required and can be one of the following:
                -erase          Global erase of the flash memory device (no input files)
                -flash_noubl    Place single bootable image in the flash memory device (single input file)
                -flash          Place a secondary user boot loader (UBL) and application image in the
                                flash memory device (first input file is UBL binary, second input
                                file is the binary application image)
                -flash_dsp      Place a DSP secondary user boot loader (UBL), an ARM secondary user boot loader
                                and the application image in the flash memory device (first input file is DSP
                                UBL binary, the second file is ARM UBL binary, and the third input file is
                                the binary application image). This is only used for OMAP-L137 devices.

        -targetType <Target>    Specify the exact target type within the OMAP-L138 family.
                <Target>                One of OMAPL138, AM1808, INTDEV0, C6748, C6746 (default is OMAPL138)

        -flashType <Flash>      Specify exact flash type among supported types for the platform.
                <Flash>                 One of SPI_MEM, NAND, NOR (default is SPI_MEM)

        <Options> can be the following:
                -h                      Display this help screen.
                -v                      Display more verbose output returned from the target device
                -p <PortName>           Use <PortName> as the serial port (e.g. COM2, /dev/ttyS1).
                -baud <BaudRate         Uses <BaudRate> as the serial port baudrate (defaults to 115200)
                -appStartAddr <Application entry point address> Specify in hex (defaults to 0xC1080000)
                -appLoadAddr  <Application image load address>  Specify in hex (defaults to 0xC1080000)

If you already have any uboot running, no longer need flash tools. In uboot there are commands to read/write/erase NAND or NOR flash.

If ethernet is working, you can tftp data to RAM and read/write to NAND/NOR. If only UART is OK, using Kermit or xModem to transfer data to RAM.

 

Kiung Chung Wong said:

_Hi,

_{I found another url that shows how to set the environment variable for library search path. I tried that, and now my build works fine.}

http://processors.wiki.ti.com/index.php/Rebuilding_the_Flash_and_Boot_Utils_Package

C6x Compiler Tools

• These are available free of charge: https://www-a.ti.com/downloads/sds_support/TICodegenerationTools/download.htm
• After installing, add the following Windows environment variable: C6x_C_DIR = <Path to lib directory of Code Gen tools, i.e. C:\Program Files\Texas Instruments\C6000 Code Generation Tools 6.1.11\lib>
• Add the bin directory of the TI C6000 Code generation tools to the system path environment variable (i.e. "C:\Program Files\Texas Instruments\C6000 Code Generation Tools 6.1.11\bin")

_rgds,

_{kc Wong}

 

 

KC,

I have tried that out , I can even check that using printenv PATH but still it gave me error message that it cannot find the library but I am through with that (by copying required library to the project folder ) and 3 .exe files are generated on compilation the problem is that running this .exe I can see progress bars and even a message that flashing completed ON the EVM but no u-boot message which means probably it doesnot execute what it says(loading in flash ) .Same is the behaviour of the prebuilt available sfh_OMAP-L137.exe files present in v2.11,v2.15, v2.20  apart from a v1.00 .exe(which works fine ) for which source code is not available 

 

I am able to see BOOT ME on the custom board with the baudrate you suggested and even on 115200 . Thanks for the explaination of your understanding. Also at some point I want to change the address at which these binaries are loaded in flash . I see an option -appStartaddress , -loadaddress , and it says by default C1080000 does that mean it loads directly into RAM and not in flash??

 

 

 

Calvin,

I am not going for using u-boot  to reflash the SPI flash as this is to be used in production for flashing large number of boards and it would be easy and fast to do it through UART , right now its been done through CCS tools. 

 

 

Is it possible for any one of  you to try out a new version of sourceforge v2.11,v2.15 or v2.20 or if you have tried as if that one works for me  i can go ahead and make code modifications and compile it using the 'make' as I am able to compile 

May be according to what KC mentioned  it could be the flash writer that is loaded in RAM which writes ubls to flash is the one causing problem but I would assume that the versions available on sourceforge should work right away atleast for EVM 

 

Thanks

NIKHIL RAJPAL

Hi 

I have few more questions

-when I run sfh_OMAP-L137.exe(v1.00) file it probably would load some flashwriter code which takes data(binary files) over UART and write it on the flash but I am just runing one file on the host PC which does it all .Does that mean the flashwriter to be loaded on the OMAP is packed inside this .exe ?? because I am not using anything else for writing on flash

 

-Is there some reference link which tells what does the OMAP expect in reply to BOOTME( as I am considering an option of writing this over by myself ) whether its an ais format file ?? What is the file format of the binary files as I will have to rip off the headers to get the binary data which is to be written on the flash ??

 

Thanks

NIKHIL RAJPAL

NIKHIL RAJPAL67586 said:

Also at some point I want to change the address at which these binaries are loaded in flash . I see an option -appStartaddress , -loadaddress , and it says by default C1080000 does that mean it loads directly into RAM and not in flash??

 

My understanding is the location for the flash is fixed for both ubl (address 0) and u-boot (address 0x10000), it is hard-coded.

As for option -appStartaddress , -loadaddress, they will eventually become part of the header which will be used by ubl when loading the app.

These are addresses used by ubl to load application into RAM to run, not addresses in the flash used by flash writer when writing to flash (you may refer to the below post). 

http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/72080/261749.aspx

rgds,

kc Wong

NIKHIL RAJPAL67586 said:

-when I run sfh_OMAP-L137.exe(v1.00) file it probably would load some flashwriter code which takes data(binary files) over UART and write it on the flash but I am just runing one file on the host PC which does it all .Does that mean the flashwriter to be loaded on the OMAP is packed inside this .exe ?? because I am not using anything else for writing on flash

 

Based on my undertanding, yes, the different flash writers are embeded in the serial flasher executable. Serial flasher will then pick the correct flash writer based on the flash type, and download it into ARM internal RAM through UART. Once this is done, ARM ROM bootloader will transfer the control to this flash writer. Flash writer will then communicate with serial flasher to get both ubl and u-boot through UART, and write them to flash of course.

 

NIKHIL RAJPAL67586 said:

-Is there some reference link which tells what does the OMAP expect in reply to BOOTME( as I am considering an option of writing this over by myself ) whether its an ais format file ?? What is the file format of the binary files as I will have to rip off the headers to get the binary data which is to be written on the flash ??

 

 You might want to refer to this doucment  "Using the OMAP-L138 Bootloader". Hopefully it helps.

 http://www.ti.com/lit/an/sprab41d/sprab41d.pdf

By the way, I just notice that you are using OMAP-L137. For OMAP-L137, if I remember correctly, the DSP will be brought out of reset before ARM. So, when you use serial flasher, you need to provide 3 images in the following order with the below option.

                -flash_dsp      Place a DSP secondary user boot loader (UBL), an ARM secondary user boot loader
                                and the application image in the flash memory device (first input file is DSP
                                UBL binary, the second file is ARM UBL binary, and the third input file is
                                the binary application image). This is only used for OMAP-L137 devices.

rgds,

kc Wong

 

Hi:

I'm a little confused what you use? OMAPL137 or OMAPL138. For OMAPL137, It boots from DSP. For omapl138 it boots from ARM.

The omapl137 boot steps can be seen from wiki "OMAP-L137 bootloader" ,"restoring/flash omap-l137 bootloader", "serial boot and flash loading utility for omapl137".

I give simple summary here:

DSPROM Bootloader (or named ROMBUL, dsp app) -> DSP User bootloader (or named DSPUBL, dsp app in AISgen format ) -> ARM User bootloader (or named ARMUBL, arm app in binary format) -> uboot ( arm app in binary format) -> Linux (arm app )

For omapl138 (Maybe I'm wrong, confirm with wiki yourself)

DSPROM Bootloader (or named ROMBUL, arm app) -> ARM User bootloader (or named ARMUBL, arm app in AISgen format ) -> uboot ( arm app in binary format) -> Linux (arm app ).

To convert DSPUBL into AIS format, you can use tool  inside board utility or you can download AISGen tool form TI's website.

For omapl137, the host side app (C#) will communicate with ROMUBL and download the writer app ( binary format ). After that host side app will talk with the writer app and transfer DSPUBL, ARMUBL and uboot to omapl137, then writer app will burn them into flash.

After that the SPI flash or NAND flash have DSPUBL, ARMUBL & u-boot, switch boot mode to match memory configuration and reset for boot. If nothing happens, you may need to add some code like GPIO flashing or UART dump message to these UBLs (of course you should rebuild it, burn again) and see which step blocked.

The best way to know the communication mechanism mentioned in the bootloader document is checking the C# code.

I think each version of board utility can work fine on 3rd party emulation board,like spectrum, logic PD .... However due to host PC setting and custom board and components difference, some tools may fail to work and need to modify a little.

I use  OMAP-L137_FlashAndBootUtils_2_20 and it works OK.

CalvinTai said:

For omapl137, the host side app (C#) will communicate with ROMUBL and download the writer app ( binary format ). After that host side app will talk with the writer app and transfer DSPUBL, ARMUBL and uboot to omapl137, then writer app will burn them into flash.

Hi Calvin 

I am using the OMAPL137 

Yes I have used that sequence of DSPUBL , ARMUBL , UBOOT and even linux kernel on the arm on Spectrum Digital EVM and custom board BUT through CCS tools not through serial port . I had modified DSPUBL ,ARMUBL, uboot for custom board and even the spi flash writer which works through CCS (jtag) . I want to do it through 

Firstly thanks for the summary which makes clear the point that host side app communicates with ROMUBL and downloades the wrter app . Is there any way that the whole code can be debugged along with C# and the flash writer that it downloads ?  I am basically thinking to distinguish which one has the problem as I know the ubls have worked other way and are directly from the PSP . I had tried forming projects out of c#files (beginer in c#) in visual studio but with lots of errors .. 

Now the v2_20 works for you is again a good point as it when i use that to load ubls(which I know have been working when flashed through CCS writer app or FlashAndBootUtils v1.00 (for which there's is no source code) )  I am left with either the versions using which i dont get any uboot message or version without source code . I will try out with flashing blinking led code to check with v2_20 

 

CalvinTai said:

I think each version of board utility can work fine on 3rd party emulation board,like spectrum, logic PD .... However due to host PC setting and custom board and components difference, some tools may fail to work and need to modify a little.

 I am trying to form a project out of the SPIwriter directory  files and supporting files to debug in CCS to find out if thats the problem . 

 

CalvinTai said:

For omapl137, the host side app (C#) will communicate with ROMUBL and download the writer app ( binary format ). After that host side app will talk with the writer app and transfer DSPUBL, ARMUBL and uboot to omapl137, then writer app will burn them into flash.

 Who accesses the files from the Host hard disk is it the c# (which I would expect  c# command line app  to read and dump on uart and the writer app running on DSP is receiving over uart and writing on SPI ) but I see some file reading code in the SPIwriter source which makes the thinking ambiguous ??

 

I also intend to change the addresses where these binaries are to be loaded in the flash  as I have integrated DSPUBL in our DSP app and has a bigger size to fit into current sets of addresses. Any suggestion welcomed

 

Thanks

NIKHIL RAJPAL

 

 

 

Hi

On checking with a simple led blinking app loaded through serial flasher ON EVM it works fine (even with v2_20 and 2_15). BUT using the bootloaders it does not show any uboot messages and same bootloaders loaded through CCS work fine . I have checked the addresses at which these are loaded in flash , both CCS tool and serial tool load them at same address.. I am puzzled what could possibly be wrong 

-bootloaders - no as they wrk fine with CCS tool

-serial flasher - it wrks fine loading led app 

Can it be that -flash_noubl option works and -flash_dsp option doesnt work??

 

 

I made some changes in the code for serial flasher to work on my custom board  like the PLL , uart divisor , uart port no and spi port no .. And I could see serial flash application going beyond the point i was stuck up earlier .. ( I was earlier stuck on "Waiting for SFT message " nothing after that) But now it shows progress bars but gets stuck up at Verifying with 2nd progress bar showing 100% but message displayed is still" Verifying" not " Application programming complete"

I saw in the modification section to make changes to the sdram timings . Is  sdram even used when I am flashing only DSP app i.e using flash_noubl option ???

Regards

NIKHIL RAJPAL

Hi,

Below is based on my understanding.

There are 2 versions of flash writer, one is used in CCS through JTAG, the other one is used with serial flasher through UART.

I think the CCS version is the one which you see some file reading code. This is the interactive process that it will prompt you for file name in the CCS console.

There is another version for serial flasher, which will get the necessary files through UART. There should not be any interactive code as in CCS version.

rgds,

kc wong

Hi:

Since you can run boot sequence successfully from CCS. The possible problem maybe configuration difference.

In CCS, there is a GEL file to make chip setting, you can check what setting included. For DSPUBL, the setting comes  from AIS embedded commands. I suggest you still use the same UBLx (without modification at first) and use , compare the GEL setting with AIS setting.

If you use command line utilities, you can check OMAP-L137.ini for the setting,which located at \OMAP-L137\GNU\AISUtils. If you use "AISGen for D800K003", you can check them on the GUIs directly.

The writer option -flash_dsp is suitable for used burning all  boot loaders of omapl137 into Flash at a time. Other options include load a test program to board and run (suitable for running test program) or options for burning ARMBUL, uboot  at a time (for OMAPL138 I think).

"waiting for sft message" means host app is waiting omapl137 writer app to send message to it but no message or improper messages comes in. You have to debug to see what happened.

The DSPUBL, ARMUBL and uboot have no error message dump most of the time, that's why users have no idea what's going on. You may have to add LED flashing or UART message into these apps if you need to debug. The JTAG maybe of no use during debug since it only runs when many things are fine, you can try.

C# is easy to debug if you build them successfully in visual studio. It's easy to set break points, run steps ... . I don't know why you compile with so many error messages, I can compile them easily.

nandwriter, DSPUBL,  ARMUBL runs inside omapl137, not run at SDRAM. If you have set SDRAM configuration in AIS or GEL, you can put them in SDRAM to run, for example put at the address 0xc1080000. But I don't suggest to do this because it's another possible variable makes system halt if SDRAM is not working properly. Uboot will run from SDRAM, if SDRAM is not working, uboot will not run successfully.  To see where these application runs, you can check the map files after building.

 

Kc ,

 

I was refering to source code in /OMAP-L137/CCS/SPIwriter........... Is it not the code that runs on target device to write on the SPI flash , if no I am mistaken there and probably code in / Common/sft is what runs on the target and receives on the uart which has no file reading 

 

 

Calvin ,

 

refering to the boot sequence when I dont see the uboot messages but I can verify that after boot up it reaches the armubl which has  a feature to disable the DSP side and I am not able to connect to the DSP but when I load a new armubl which skips that step I am able to connect to the DSP which means its reaching till armubl stage 

 

 

 

CalvinTai said:

If you use command line utilities, you can check OMAP-L137.ini for the setting,which located at \OMAP-L137\GNU\AISUtils. If you use "AISGen for D800K003", you can check them on the GUIs directly.

 

I will look for those files . 

 

For custom board

I am past that message of "waiting for sft " 

and I can see the progress bars going to 100% but stops at Verfying   for ever  what would make it hang up there ??

 

 

CalvinTai said:

C# is easy to debug if you build them successfully in visual studio. It's easy to set break points, run steps ... . I don't know why you compile with so many error messages, I can compile them easily.

I will try out once more to form a project .Are there dependencies in those files as I was having errors which say multiple declaration of symbols .. in files from same folder 

 

 

Is there any specific need for it to be in C# would it be a good idea to write the command line app again in c ??

CalvinTai said:

The DSPUBL, ARMUBL and uboot have no error message dump most of the time, that's why users have no idea what's going on. You may have to add LED flashing or UART message into these apps if you need to debug. The JTAG maybe of no use during debug since it only runs when many things are fine, you can try.

Thats a good idea I can try that out on EVM as my custom board does not have leds. 

 

Thanks 

NIKHIL RAJPAL

Ya, I guess that is the correct folder.

I only see 2 files there in Commns\sft\src, (1)sft.c and (2) uartboot.c.

If you want to add in debug message in these files, I think you need to turn on the other UART. You might not want to use the same UART that is communicating with serial flasher.

By the way, if you need to check what is the chip setting made by GEL file, I think the below Debug Gel Files will be handy.

http://processors.wiki.ti.com/index.php?oldid=58310

rgds,

kc Wong

Thanks Kc

 

I am considering forming the sft and sfh by myself using some parts of the current versions as compiling in these files is through make files (probably scripts) and I dont know how much of things about it  like how does a bin file (sft ) gets embedded into .exe ??

 

I also had question regarding the CCS tool for flash writing which I have been using for a while without any problem (wrks fine)  

How does the following happen

 Code running on the OMAP target has file reading code . How can instructions runnning on target access the files on the hard disk of host PC 

""  if(!feof(fPtr)) {

nbytes = fread(tx, 1, page_size, fPtr);

}

tx[nbytes] = '\0';

 

win_flash->read (win_flash, i * page_size, page_size, (Uint8 *)rx);""

Its part of code from CCS tool which accesses flash which sounds ok but accesses files on hard disk i.e host PC (and this runs on target!!)???

 

Ha, tough questions, I do not know the details as well. I think TI staffs can comment it better especially your second question.

Anyway I still share my understanding here ...

NIKHIL RAJPAL67586 said:

I am considering forming the sft and sfh by myself using some parts of the current versions as compiling in these files is through make files (probably scripts) and I dont know how much of things about it  like how does a bin file (sft ) gets embedded into .exe ??

For this, you need to look at the makefile that builds the sfh in \OMAP-L13GNU\sfh folder especially below lines. I guess the DOTNETCOMPILE is actuallu C# compiler, and it actually combines all the SFTIMAGES into a single executable - serial flasher. The serial flasher will access these images in EmbeddedFileIO module, I guess. Anyway, I am not familiar with C# compiler.

 $(EXECUTABLE): sft $(OBJECTS)
ifeq ($(shell uname),Linux)
  @$(MONOCOMPILE) -t:exe $(patsubst %,-resource:%,$(SFTIMAGES)) -out:$(EXECUTABLE) $(OBJECTS)
else
  @$(DOTNETCOMPILE) /t:exe $(patsubst %,/resource:%,$(SFTIMAGES)) /out:$(EXECUTABLE) /win32icon:$(ICONPATH) $(OBJECTS)
endif 

____________________________________________________________________________________________________________

When flash writer is built in the CCS, the standard library has different implementation. I guess it is in rts32e.lib or rts32earm9.lib, not sure which one.

For standard input and output, they have been redirected to CCS console through JTAG.

For file access functions, the implementation may have some kind of TRAP instruction to switch the control back to CCS (similar to when breakpoint is hit), and the target is halted. The CCS will then read the file, and put the contents in the target memory, then resume the target from there. This is what I think ............

rgds,

kc Wong

 

 

 

I just did a google search, I guess RTDX is the technology behind it that does the wonder.

http://processors.wiki.ti.com/index.php/Real_Time_Data_eXchange_(RTDX)

http://processors.wiki.ti.com/index.php/High_Speed_RTDX_(HSRTDX)

http://www.tij.co.jp/jp/lit/wp/spry012/spry012.pdf

 

I have made up my mind to write a simpler sfh (c# ) and sft(c) one specific to custom board using the some parts of source code available  but I have some questions

- Is there any reference where I can find what does the omap expect after it spits out BOOTME .??

-where does it place whatever it receives on uart in uart boot mode ? on RAM? by itself ? does it jumps to starting point of sft code after loading on the RAM ?

- How does it know till when to accept data on uart ? probably this can be set but is there some convention

 

Thanks 

NIKHIL RAJPAL

 

Hi:

The bootloader document (mentioned by KC in previous mails) have detailed description how ROMBUL handshake with Apps (AISformat & handshake mechanism). The sfh C#  source codes  follow the spec doing handshake and is a good example for understanding the protocol.

While C# app handshaking with nandwriter, the app will talk to target  writer app where to burn (in Flash) and where to run (in RAM/SDRAM) DSPUBL, ARMUBL & uboot by transfer header info to target writer app.  The header will burn into flash also at 1st page of each UBLs block location by target writer app. See sfh source codes and target writer app source codes for details. 

The target writer app is transferred by C# app to ROMUBL app, then put in internal RAM of omapl137. Then C# will ask (via AIS commands) ROMUBL program to  jump to target writer app's start address, then target writer app take over and talk with C# and do UBLx loading & burning.

I suggest running above C# app, writer app, UBLx via EVMs, not custom board. By reading source codes, or building and running C# app step by step, you will understand the details. After that you can focus on hardware issue when booting custom board.

hi Calvin

 

Yes , thorough reading the bootloader document and comparing the sequence in code made sense. But still I could find two approaches 

I have attached txt file mentioning both . 

(2nd approach i find as a result of flashing small led application in evm board)

soure for 1st approach i can find in sfh.cs and for 2nd in sfh_ais.cs (along with sfh_ais_util.cs,ais.cs) and it also matches with the bootloader document. I just want to confirm that this is the approach needed as according to first approach if i supply  "    ACKX8X4X40000" through the terminal manually it doesnt respond with BEGIN but instead with a letter R 

Do you know anything about that behaviour ?? and if u can confirm which of the two files( is my ans sfh_ais.cs correct) have the main function that should execute on host  as both of them have.. 

 

Right now I am debugging using sfh_ais.cs and sfh_ais_util.cs in visual studio (forming a project using sfh.cs and sfh_ais.cs gives errors as namespace TIBootAndFlash is present in both of them so I have formed different projects in vc#) 

 

 

Hi:

I use follow files to build sfh-omapl137 C# project:

in visual studio, I have following files:

ais.cs, aisparse.cs consoleutility.cs, crc.cs, debug.cs, device_name.cs, embeddedfileio.cs, fileio.cs, serialio.cs, sfh_ais.cs. Together with sft_omapl137_v2_nand.bin (or you can add all resources to c# projects, as mentioned in makefile below, it will use correct bin file download to target according to the command line arguments).

With above files add to C# project, it will build easily I think, without any compile error.

Above files are base on the makefile in the gnu\sfh:

REMOTESOURCES=$(PROGRAM)_ais.cs AIS.cs AISParse.cs device_name.cs Debug.cs CRC.cs EmbeddedFileIO.cs FileIO.cs SerialIO.cs ConsoleUtility.cs

....

SFTIMAGES=$(wildcard ../sft/sft_*.bin)

Compare above you will have more ideas which files used in what project by checking corresponding makefile.

 

From your attachment, it seems 1st run not complete yet.

The 2nd run matches what I see in my system when download successfully. It shows progress bar to 100% and said "Operating complete...". I use the tools a lot of times and have confidence if it shows the text.

Do you remember to switch to related flash boot option to see if the program runs successfully?

If you can see download program successfully (like 2nd run) and system not work as you respect (like no LED-flashing when switch to flash boot). Normally you can focus on the configuration setting, not burning tools (lower check priority I suggest).

Check AIS configuration 1st, then check source programs.

AIS can set GPIOs, powers, PLLs, SDRAM... checking if it matches the HW or not. If not properly setting, the result will be worng.

For some source programs, they will configure again the GPIOs, powers, PLL, SDRAM..., maybe it changes the behavior AIS set.

Since you can download LED-flash,  why not donwload UBLs and debug them directly. I think it's the configuration mismatch HW so u-boot not seen, anyway debug and dump some messages will make things clear.

 

 

 

 

 

Hi Calvin,

 

I have debugged the c# (host) side of the project in vc# and works fine on the evm (even wrks same forming project out of files u mentioned thanks) and not on the custom board it gets stuck at "Verifying stage "  if I jst comment out the verifying code  sft passes done and sfh shows message done (assuming atleast it would work atleast 1/5 chances) to jst check but it doesnt and 

when I try to erase (verification commented) , after erase complete I can still see the app running on the DSP( which was previously loaded through CCS)

I realized that CCS tool had worked fine because I had made some changes for a different type of flash on our custom board . Its not winbond , SST instead .

I tried out by making them on sft but couldnt do it successfully and had already started writing own sft 

 

I have few questions

After forming the sft (new) project through CCS can I  jst simply use AISgen utility to form bin file out of .out file that CCS forms or there is something special in those make file which generate these sft bin files (as I had seen use of some cl6 compiler )??

 

Is it ok to simultaneously write on spi each and every byte  while reading on the uart ?? 

Is there any other way I can verify the spi write by not using sdram to store image ? I doubt the sdram on few of our boards . 

 

 

Regards

NIKHIL RAJPAL

 

Hi:

CCS4 use hex470.exe to convert out to bin. See  postBuildStep_BOOT_xxx.bat.

For SPI part, by my experience, you can do other things when burning flash, but make sure the supply voltage is good (no much voltage spike or swing) if you do many things simultaneously.

The internal RAM size is large enough for SPI flash buffering.  You can verify burned result either "verify byte one by one" or "checksum method" if memory size is a issue.