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.

SYS/BIOS Hello example program won't run

Other Parts Discussed in Thread: DM3730, OMAP3530

Hello,

 

I am trying to get the Hello example to work from the SYS/BIOS example. I'm running CCS v5.3, BIOS v6.34.01.18, XDC v3.24.05.48. I got the program to compile, I am using a DM3730 chip with a Target of "ti.targets.arm.elf.A8Fnv" and a Platform of "ti.platforms.evm3530", was told this is the closest platform since there wasn't any DM37xx.

In my linker.cmd file I added:

boot > 0x82000000

{

-l boot.aea8fnv<boot.oea8fnv>(.text)

}

and verified in the .map file that the start address is as above. I then use "armhex.exe file.out -o file.bin" to convert the file. Finally, through RS232 I use the loadb command from uboot (which loads the binary to address 0x82000000) to load the file and then "go 0x82000000" to run the program. There is no output!

I've added a printf() statement along side the System_printf() since I read in other boards that System_printf() sometimes does not work.

Now, where am I going wrong? Is uboot cutting me off from transmitting on UART3? How to tell which UART SYS/BIOS is using for stdio?

Also, if I save my file.bin to my mmc and rename it to uboot.bin will x-loader load it up and run it (assuming SYS/BIOS will do the HW init in the background)?

 

Thank you

  • Dustin,

    Have you tried running the hello example within CCS before trying to boot via RS232?  That should be a first step.  

    Also, for the different steps to get it to boot remotely… if you haven’t worked those out yet then it would be best to get those steps resolved for a non-SYS/BIOS program first, before trying it with a SYS/BIOS program.

    Getting back to the basic SYS/BIOS Hello example… it will not produce any output to a UART, but to the CCS console instead.  System_printf() uses “back end” support functions for routing and displaying the output.  The two standard built-in modules for this are SysMin and SysStd, as described here:
    http://rtsc.eclipse.org/docs-tip/Using_xdc.runtime_System  If you want to send the output to a UART you will need to add your own system support module, similar to SysMin and SysStd.

    Regarding “is uboot cutting me off from transmitting on UART3”, creating file.bin, uboot.bin, mmc file, x-loader, etc., I don’t know if there are many users on this forum familiar with these different tools.  If you don’t get much response on this forum you might want to try the Linux forum for those questions:  http://e2e.ti.com/support/embedded/linux/default.aspx

    Scott

  • I understand what you are saying...I'll focus more on loading it and toggle some GPIO pins nstead of UART. I don't have much time to spend on this and was hoping to find a manual for using SYS/BIOS that would answer some of these basics. If there is one can you point me in that direction, I'm sure this is a common question with an easy answer because there has to be people using SYS/BIOS.

  • Dustin,

    I asked around, looking for examples of booting programs on a DM3730.  While doing that I realized that this device is not on the supported device list for SYS/BIOS.  (You can find the list of supported devices by following the “Device Support” link in the SYS/BIOS release notes.)  Sorry that I didn’t realize this earlier.  I asked around some more, and there are no current plans add this support.  

    It may be possible to fool the tooling to some extent, and continue to build your application as if you are using an OMAP3530 device.  You’d probably need to make some tweaks to adjust for speed (and maybe memory?) differences.  But it is not clear what issues you might run into, and if it will be an easy road or a tough one.  Someone may have done this before, but we’ve (the SYS/BIOS development team) not heard about it.

    If I hear back from my pings for examples of booting generic programs on the device I’ll post that info back to this thread…

    Scott