• State Resolved
  • Locked Locked
  • Replies 14 replies
  • Subscribers 100 subscribers
  • Views 1877 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

ICE V2 / AM335x SPI boot in SDK 1.1.0.5 prebuilt binaries vs. code

utelia
Intellectual 290 points
Other Parts Discussed in Thread: SYSBIOS

Hello,

I am taking into use ICE V2 and using the provided tools and the boot_SPI (and led-blinking SPI) binaries in am335x_sysbios_ind_sdk_prebuilt_01_01_00_05, I can make the device boot from SPI and start the led-blinking application.

When trying to do the same with the am335x_sysbios_ind_sdk_1.1.0.5\sdk\starterware\bootloader example code, which I compile and post_build myself, I however cannot make it boot up.

There are things that make me think that something is wrong:

(1) The StarterWare example does not compile as such, but I have to undef the MMCSD flag from the CCS project

(2) in the post_build.bat, I have to remove the citation marks from the line

set dirtemp="C:\isdk_temp_%random%_%random%" 

to make the script work.

After these changes, I can compile and build the SPI boot loader code, and also run the post_build.bat script, which creates the boot.bin and boot_SPI.bin files. The resulting files are slightly smaller than the prebuilt ones, but I would have attributed that to removing the MMCSD support. (Which I had to do to make the project compile).

I now have three different boot_SPI.bin files:

(A) one from the prebuilt binary folder

(B) one from C:\scanner\Main\Host2\ccsv6\am335x_sysbios_ind_sdk_1.1.0.5\sdk\starterware\binary\armv7a\cgt_ccs\am335x\evmAM335x\bootloader 

(C) and the one which I built myself

Both (A) and (B) work, although they are different when seen with beyondCompare.

(C) does not work.

On top of the possible differences in the actual code, indicated by (1) and (2) above, the post_build.bat usage might make a difference. I am using it as follows:

post_build "C:/ti/ccsv6" "C:/ti/ccsv6/tools/compiler/arm_5.1.5" "c:\Users\user1\temp_spi" "boot" "c:\Users\user1\t
emp_spi" "0" "3"

Should I give some load and run addresses? (As it is now, it is supposed to use the defaults).

My main question is, however, can you please point me to any omissions I might have in my process above? Did I miss something, or could it be that the prebuilt examples are not from the code provided with SDK/StarterWare? Is the code available, with instructions, which was used to create the prebuilt examples?

I am using ARM compiler tools 5.1.5

  • 0
    TI__Guru**** 393215 points

    Moving this to the SYS/BIOS forum.

  • 0
    TI__Expert 7360 points

    Hello,

    Are you sure you are following the steps mentioned here - http://processors.wiki.ti.com/index.php/AM335x_SYSBIOS_Industrial_SDK_01.01.00.05_User_Guide#Building_Bootloader.C2.A0 ?

    Thanks,
    Vinesh

  • 0 in reply to Vinesh Balan
    Intellectual 290 points

    Thank you for your suggestion. 

    I went through that chapter and although I hadn't followed it (but just trusted that the example project should be buildable as such), the differences were very small.

    - I had not compiled the libraries myself, but was using the original project's include path "${workspace_loc:/${ProjName}/starterware_libs}" which resulted in accessing some prebuilt versions.

    I imported the projects, built them and replaced the earlier include path with the new ones (for the compiled projects).

    - I noticed that the need to remove the MMCSD flag is actually in the intructions, so having to do that is not an error in the example like I thought.

    However, I cannot see a change in the operation. 

    Still, the situation is that with the Fastboot_SPI and boot_SPI binaries, it boots up but not with the one I built.

    None of the prebuilt examples provides a ready-made out file so I could check if my post_build bat usage is right or wrong.

    Do you have any advice regarding whether I should give load and run addresses when running the post_build.bat, and in that case, what should they be? 

     

  • 0 in reply to utelia
    TI__Expert 7360 points

    Ideally, you do not have to modify any of the sources/project files to get it work. The build binaries are packaged as-is in the pre-built binaries.

    Regards,
    Vinesh

  • 0 in reply to Vinesh Balan
    Intellectual 290 points

    Hello,

    Looking into SDK 1.1.0.4 and 1.1.0.5, the boot_SPI.bin are binary identical in both! However, there are rather significant changes in the code between the two releases. 

    I think this means that the code in 1.1.0.5 was not used when generating the the binary files which work in the set-up, which would mean that it is necessarily not a very good starting point. 

    My initial finding is also that when I take the 1.1.0.4 code, I cannot produce a working SPI bootloader. Also in this case, I see compilation issues (with UARTprintf macro definition) which make me think this code revision might not have been the basis for the binaries found in the directory (both for 1.1.0.4 and 1.1.0.5).

    So the situation is still that I can make it work with the supplied binaries but not when I compile the same code examples by myself.  

    Any suggestions where to look next?

  • 0 in reply to utelia
    TI__Expert 7360 points

    Hello,

    It seems the binaries available at starterware\binary\armv7a\cgt_ccs\am335x\evmAM335x\bootloader were not updated in 1.1.0.5, but the pre-built binaries were definitely updated(checked via beyond compare).

    Are you using multiple SDKs at the same time? If yes, then please make sure to configure IA_SDK_HOME properly.

    Regards,
    Vinesh

  • 0 in reply to Vinesh Balan
    Intellectual 290 points

    Hello,

    Thanks for your suggestion.

    It turns out that my installation did not have IA_SDK_HOME set at all. I set it manually in Windows System variables (and re-imported the projects etc) and it helps in that way that the bin files are now generated automatically. With BeyondCompare, I however verified that the binary is identical to the one I was able to generate manually, so unfortunately, this does not help with my actual problem.

  • 0 in reply to utelia
    Intellectual 290 points

    I made another trial by compiling myself the led-blinking example code which I have been using as the App stored in SPI (and which I also took from the pre-built directory). With some struggle, I was able to compile the same source code and successfully run that in ICE v2 (code loaded with an external emulator, no SPI boot involved).

    However, when applying post_build.bat to it, I cannot make it start up from the SPI even if I again have the provided/prebuilt SPI bootloader in place. This proves that even if I can build code which runs on ICE v2, I don't seem to be able make into SPI in the right format.

    This would now suggest there is something wrong in my work flow and/or CCS / SDK settings(?) when taking an .out file and making it first into the .bin and then transferring that into the _SPI.bin format. 

    Having access to an .out file used to generate the pre-built binaries would strengthen this assumption.

    Would this ring any bell?

  • 0 in reply to utelia
    TI__Expert 7360 points
    Hello,

    Are you modifying the post build script? If yes, can you post the same?

    Regards,
    Vinesh
  • 0 in reply to Vinesh Balan
    Intellectual 290 points
    Hello,

    In the beginning, I had to remove the citation marks from one line in bat file (as explained above). For this purpose, I also renamed the post_build.bat and used that when manually generating the bin files. However, when I added IA_SDK_HOME into Windows System variables (with the correct path), the bin generation worked directly off the CCS Build, and it was using the original path and original unmodified post_build.bat.

    Would you have available the .out file from which the bins in the SDK delivery are generated? That would help me to see what part exactly is failing.

    My next effort (later today), will be to re-install the SDK to see if it has an impact. (Or are you confident that the IA_SDK_HOME was the only environment variable which might have had an impact?)
  • 0 in reply to utelia
    TI__Expert 7360 points

    Hello,

    If it's about the bootloader, I do not think there is any other impact. For application, there can be an impact of the tools used.

    Here are some suggestions that you can try

    • Rebuild the bootloader with the appropriate settings mentioned in user guide
    • If the bootloader does not come up, please check the UART logs to understand where it has gone bad. You can also debug the BL by putting a hardware breakpoint at 0x402f_0400 and then loading symbols
    • Build the application. You can verify the run and load addresses with the Map file(check if it's the same in post build steps of the application. While building the application make sure that the correct tools are used(SYSBios, XDC etc.)
    • If not booting, check the UART logs to see where it has stopped. In SPI mode, you can try putting a hardware breakpoint at 0x8000_0000(Start of application) to check if the bootloader is giving control to the application

    Again, all these are tested thoroughly to work as-is! If you have made changes in some project settings, re-installing(or reverting changes if you have a version control system) is recommended. 

    Regards,
    VInesh

  • 0 in reply to Vinesh Balan
    Intellectual 290 points
    Hello,
    I installed a second copy of SDK 1.1.0.5 and this helped. All the small issues disappeared and the output bin file is also different - and most importantly, it works. Thank you for your help and support!
  • 0 in reply to utelia
    Intellectual 290 points
    There is actually more to this story.

    I should have stated in my initial question that we also had the BBB patch installed on top of the SDK/StarterWare (http://software-dl.ti.com/dsps/dsps_public_sw/am_bu/starterware/latest/index_FDS.html). This is for a good reason because we are currently working with both platforms.

    When working myself back to a stable situation i.e. doing everything in a systematic and documented way, and returning to version controlled environment, I noticed that bl_platform.c and bl_platform.h coming out of the BBB patch do not compile for the ICE V2 (or evmAM335x) target. This was also the root cause for my initial complaints about having to modify the projects (both the bootloader and the LED demo) here and there to make them compile. At the time, I made those small modifications and forgot about the matter. Also, I could make the LED demo run (although not off the SPI boot) so I did not suspect the application itself was broken.

    It is not clear to me which one of the two causes: (1) the potentially bad installation of SDK and (2) the later discovered issue with the BBB patch , actually was the root cause. (It might have been both). The important thing is that the issue is solved.

    Should the BBB patch work together with ICE V2? Based on the above, it does not.
  • 0 in reply to utelia
    TI__Expert 7360 points
    Glad that you figured it out. BBB patch won't work on ICEv2(not sure if it would even work on Industrial SDK). The Industrial SDK has a custom Starterware to meet the needs of the supported boards. Mixing them up doesn't look like a good idea.

    Regards,
    Vinesh