SYS/BIOS basic example does not provide output

For System_printf, you need to use the RTA tools in CCS. They are non-intrusive print statements supported by SYSBIOS.

http://e2e.ti.com/support/embedded/bios/f/355/t/180028.aspx

Regards,

Rahul

Hi,

Thanks for your answer.

I followed the suggestions in the thread you porvided. I get the error that linking failed for some ethernet related functions and _TaskSelf.

I'm wondering whether there is not a more fundamental problem with my setup, as the program module has a red dot in XGCONF and the breakpoint at the start of Main() is never hit, although the debugger state is running.

Furthermore, when I managed to get the RTA Agent working (using the legacy tools) the events all looked like this:

"2,440,724,675,270,019,100",403177906,,0x68,"Log_write(eventId: 8672, 0x218c0264, 0xe0400000, 0x53c22f4, 0xc6e4646, 0x0, 0xe5000080, 0x903d5b, 0x903d59)",Main Logger

The program also halted at a (seemingly) random address.

How can I verify that the program is running correclty?

Regards,

Remco Poelstra

Hi Remco Poelstra,

Which version of CCS and SYS/BIOS are you using?

Which GEL file are you using?

I would recommend starting with the SYS/BIOS hello world example.  Please give that a try and let me know how it goes.

Steve

Hi,

Thanks for your answer.

CCS is 5.3.0.00090

SYS/BIOS is 6.34.2.18

My GEL file is ..\..\emulation\boards\lcdkc6748\gel\C6748_LCDK.gel

As platform for SYS/BIOS I set evm6748, as there is no platform file for the LCDK

The hello world behaves the same. I get no output at all (from the app, the GEL seems to run fine). I've set a breakpoint at the start of main, which is not hit.

I would be really glad if you can help me to get this running.

Regards,

Remco Poelstra

Hi Remco Poelstra,

I was able to create the SYS/BIOS hello example and successfully run on my LCDK board (on ARM9).  See screen shots below.

I also attached my GEL file that's used for the ARM side.  The DSP does not have a GEL file.

3652.OMAP-L138_LCDK.gel

The GEL file should come with your CCS install.  For me, it's here:

C:\ti\CCS5.3.0.00090\ccsv5\ccs_base\emulation\boards\lcdkomapl138\gel

Steve

Hi,

I highly appreciate the time you take to solve my problem.

I've an LCDK with only an DSP. I actually take the steps you take to create the project,  except that I pick the C6748 where appropriate. Do you think it would help if I pick the ARM files while not having an ARM on board?

Please see the screenshots of the steps I've taken and the result from the app running in the debugger. The GEL file I use works fine with a Starterware only app. With Sysbios I get no output or breakpoint from the app at all.

I tried creating the hello project exactly the same way that you did.  I put a break point at main() and it reached it.

After I stepped over the lines:

    System_printf("hello world\n");

    /*
     *  normal BIOS programs, would call BIOS_start() to enable interrupts
     *  and start the scheduler and kick BIOS into gear.  But, this program
     *  is a simple sanity test and calls BIOS_exit() instead.
     */
    BIOS_exit(0);  /* terminates program and dumps SysMin output */

I saw the hello world string show up in the CIO console window.

What happens if you change your target configuration to not use *any* GEL file for the DSP?

I wonder if you're not seeing the output because you're currently not in the "CIO" console view?

Can you try changing your console view to CIO?

Steve

Hi,

I'm very sorry. In the attached screenshot you can see that the target is running, but the indicated breakpoint is not hit and there is no CIO console available. This console does indeed appear when I run a starterware-only app.

I tried this time with a GEL file specific for this project. The configuration output looks the same as always.

I've the idea that somehow the app is not started at all and that the DSP is running random code (CCS does show that it uploads the correct app to the DSP, as it does with a starterware-only app). Is there some way to check such low level things?

Regards,

Remco Poelstra

Remco,

Remco Poelstra said:

I tried this time with a GEL file specific for this project. The configuration output looks the same as always.

Can you try changing your target configuration to use *no GEL file for the DSP* and the attached ARM GEL file for the ARM9?  I think the ARM GEL file may do something to allow the DSP to operate correctly.

5707.OMAP-L138_LCDK.gel

If that doesn't work ...

Can you try turning off the "auto go main" feature of CCS?  This feature causes the application to automatically run to main() upon program load.

You have to disable this in two different places - the project settings and the CCS debugger settings.  In both places, you must delete the string "main" for "run to symbol" and also "un-check" the auto run option for "on program load or restart".  Screen shots below should help.

First, you must disable it in your project's settings:

Next, the debugger settings:

After that, reset and reload your app.  You should be at the symbol "c_int00" after loading the program.

Then can you try putting a break point at the "_args_main" function?  Do you reach that?

Steve

Hi,

I tried your GEL file, but apart from an additional "DSP Wake up" message, there are no differences. After switching forwards and backwards a few times between different target configuration files (and GEL files) I once got the sysbios app to break on main. Stepping through the code didn't work though. After the first "step over" command, the debugger switched to running and that was it.

I then tried your breakpoint manipulation.

I've no debug options for the project settings, not even with "Advanced options" turned on (see screenshot (without advanced turned on)). In Debug perspective, I do not have the menu options under tools, as shown in your screenshot. I did find a similar screen under Run->Debug options and used that.

I tried with my staterware-only app to run to c_int00 and then break on _args_main. That works.

I tried the same with the sysbios app and it does break on c_int00, but it never hits a breakpoint at _args_main.

When it stops at c_int00 it gives this message in the editor: Can't find a source file at "/db/ztree/library/trees/xdctargets/xdctargets-f40x/src/ti/targets/rts6000/boot.c"

Somehow I had expected it to try to find a source file related to the target I'm using (or is rts6000 related to my target?).

When I then Resume and Pause the app (it never hits _args_main), it stops at various points inside what seems to be Sysbios. It never did that when it didn't stop at c_int00. In the latter case it would always stop at random pointers. So there seems to be different behavior when breaking at c_int00.

It doesn't matter what GEL file I use to get the behavior as described above, but the C6748 file seems more correct to me, as there is no ARM on my chip.

Kind regards,

Remco Poelstra

Can you please zip up and attach your fully built project to this thread?  I would like to try the BIOS app you're having problems with (not the starterware one) to see if I see the same issues you're encountering.

CCS has a nice "export" feature to zip up your application.  If you right click on your project, select "export", you'll then see a wizard that will allow you to create an archive.  Follow the steps after that to zip up the entire contents.

Steve

Hi,

Attached the zipped project.

The target configuration file included is using the .GEL file for the L138 you send earlier.

I also have a "User Defined" target configuration which uses the C6748 GEL file. I mostly use that general target configuration, but for this problem it doesn't seem to really matter. It does stop at c_int00, but it never reaches _args_main.0763.sysbios_helloworld_zipped.zip

I hope you can find the problem, I would really like to get started with SYS/BIOS.

Kind regards,

Remco Poelstra

I am having the EXACT same problem as you, down to every single step and configuration. The main difference is that I am using a TMS320C6748 on a custom board that my company has made.

I have followed every instruction from every User's Guide, example code, etc. and tried all sorts of configurations, gel files, and other changes to try and get past this problem. When using SYS/BIOS, the program simply will not execute, despite the fact that it says it is (Running).

On the other hand, I can create and run a non-SYS/BIOS program with the most barebones functionality possible that just printf's. Being able to use the SYS/BIOS libraries is very important to me, however, so I am in urgent need of getting this problem resolved.

My setup, so you can compare to Remco's:

Chip: TMS320C6748 (standalone, not part of a kit)
IDE: Code Composer Studio v5.3
Connector: Blackhawk TI USB100v2 Emulator, 14pin JTAG
SYS/BIOS v6.33.01.15
XDC Tools v3.20.03.63

Thanks for any help or insight you can provide on this issue.

Cheers,
Charles Cross

I downloaded your project and built it.  I was able to run the program successfully on my end.  The app reached main and also I saw the hello world output to the console.

I was also able to run your pre-build .out file that was under the Debug directory of your attachment.  It also worked.

I suspect the issue must be due to an incorrect GEL file.

The other difference is my board has both an ARM and DSP.  I'll ask around and see if we have a DSP only board.

Steve

Charles Cross,

Does your board have both an ARM 9 and C674 DSP? Which one are you running on?

Steve

Steve,

My board has only a TMS320C6748 on it, no ARM chip. For clarification, it is also not part of the TMS320C6748 eval kit that comes already mounted to a testing board. We've simply got it mounted into our custom board that we designed which has it hooked up to all the proper power pins and some peripherals like an Ethernet controller, SPI boot flash, RS-232, and some things controlled by the GPIO. I am connecting to and uploading the program to the chip via a Blackhawk (TI 100v2) JTAG connector.

Thanks,
Charles

After digging a little bit deeper and asking around the office a bit, one possibility for what is causing this problem is that the GEL file that I have is incorrect for the configuration of the standalone TMS320C6748BZWT that I have. I don't know too much about GEL files or how to write them, but looking through the file itself, it seems to be trying to set up a configuration for the OMAP-L138, which is the chip on my PD Zoom Experimenter Board, despite having been named "C6748.gel". I've done a bit of googling, but can't seem to find any .gel files written specifically for a standalone TMS320C6748BZWT.

Does this file exist somewhere in TI-space or will I have to learn write one from scratch? (something I eventually intend on doing, once I am not pressed for time)

Thanks,
Charles

Wasn't the GEL file. I got an example program to successfully run (execute my main() function) by using DSP/BIOS 5.41.07.24 using the same .gel file that i have been using (which actually does seem to be correctly mapped configured, when compared to the TMS320C6748 datasheet).

Seems this problem may only exist with SYS/BIOS?

That's great news that you were you able to reach the main function, but could you get further than that?  Could you reach any task functions?  Can you check if your hitting the idle task?

Steve

As of about 5 minutes ago, I am successfully reading input from a dip switch and controlling some status LEDs on my board, so all is dandy in the world of DSP/BIOS. It would be really nice to have a set of wrappers/drivers for doing these sorts of operations though. I was under the impression that SYS/BIOS would provide me with that kind of functionality.

Ultimately (since I have gotten some basic IO working within DSP/BIOS), I'm not too worried about whether I'm using DSP/BIOS or SYS/BIOS, but am more interested in having a set of libraries available for easier implementation of functionality with GPIO, uPP, Ethernet, UART, and SPI Boot Flash. This is kind of de-railing the topic of this thread, but I do hope that this might help Remco get a bit further along.

Steve, if you have any suggestions for how I can get the functionality that I need from this point, whether it be in terms of using DSP/BIOS, SYS/BIOS, or something else, it would be much appreciated.

Cheers,
Charles

DSP/BIOS (as well as SYS/BIOS) does have driver and network support.  However, these are shipped in separate product packages and are meant to run on TI EVMs.  Since you mentioned you are using a custom board, the drivers may not work for that.

For networking, you need the Network Development Kit (NDK) 2.20.x and corresponding NDK Support Package (NSP) for the evmOMAPL138.

The NDK contains the core TCP/IP stack libraries, whereas the NSP typically contains the hardware specific EMAC drivers and networking examples.  You can find those here:

• NDK with DSP/BIOS 5.X support: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ndk/2_20_06_35/index_FDS.html
• Corresponding NSP with DSP/BIOS 5.x examples: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ndk/nsp_1_00_00_09/index_FDS.html

For other peripheral drivers, you should look at the BIOS Platform Support Package (PSP).  You can find it here:

• PSP for DSP/BIOS 5.X: http://software-dl.ti.com/dsps/dsps_public_sw/psp/BIOSPSP/01_30_01/index_FDS.html

Finally, most (if not all) DSP/BIOS and SYS/BIOS related software can be found on the main download page:

http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/index.html

Steve

Hi,

I tried DSP/BIOS as well (latest version) and that one runs fine!

I get the expected breakpoints as well as Raw Log output.

Are there significant differences between DSP/BIOS and SYS/BIOS concerning the low level startup?

Remco

It seems I now have a serious problem....

I noticed that SYS/BIOS loaded everything into DDR while DSP/BIOS loads everything into IRAM (SHDSPL2RAM).

Since my Staterware app loads into SHRAM, which is also not DDR, I expected some problems with DDR.

I changed the staterware app to load its .text section into DDR and it indeed stopped working. It got stuck at 0x700000.

I then changed back the .text section to SHRAM, cleaned the project, restarted CCS and rebooted the LCDK, but when I debug the app still gets stuck at 0x700000.

So it seems that my one and only working app has stopped working as well......

It also seems there is some problem with the DDR memory. I'll see what I can find out.

Kind regards,

Remco Poelstra

Some very strange things are happening here.

After some debugging CCS crashed and I had to reboot the computer. After bootup the app worked again.

But while debugging McASP and DMA related problems, sometimes the same problem came back. With no apparent reason, sometimes it was just enough to swap the location of two global buffers in the source file! e.g. change the following lines:

static int buf1[4000];

static int buf2[4000];

to:

static int buf2[4000];

static int buf1[4000];

was enough the get the app stop working. Sometimes it kept working sometimes not. It also seems there is some sort of memory involved concerning the memory locations of such variables as swapping them in the sourcefile does not move them to another location. That might be defined behavior, I don't know.

Anyway, the Starterware app is running again, DSP/BIOS works, but SYS/BIOS does not. The only difference I could find was that SYS/BIOS loads into DDR.

I've no idea how I can reliably load the Starterware app into DDR to see if there is a problem with DDR.

Regards,

Remco Poelstra

TI Staff,

Any insight yet into why SYS/BIOS won't run properly but DSP/BIOS will?

Remco Poelstra,

Are you able to get the SYS/BIOS 6.x app to work when loaded into internal memory?  Does it work?

Similarly, what happens if you load the DSP/BIOS 5.x app into DDR?  Does it stop working?

For reference, here's what the memory map of my SYS/BIOS 6.x hello world app (C674x) looks like:

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  00013152  07feceae  RWIX

Steve

Hi,

I can't get SYS/BIOS to run from internal memory.

I did an Tools-?RTSC Tools->Platform->Edit and changed all memory segments to shared RAM. (See screenshot).

But after a clean and compile I get the following error:

-----------------------------------

making package.mak (because of package.bld) ...

generating interfaces for package configPkg (because package/package.xdc.inc is older than package.xdc) ...

configuring hello.x674 from package/cfg/hello_p674.cfg ...

js: "C:/ti/xdctools_3_24_05_48/packages/xdc/cfg/Main.xs", line 156: Error: incompatible use of package 'ti.platforms.evm6748' [in C:/ti/xdctools_3_24_05_48/packages/ti/platforms/evm6748/]: version of the loaded package 'ti.platforms.evm6748' is [], while 'ti.sysbios' [in C:/ti/bios_6_34_02_18/packages/ti/sysbios/] was built with 'ti.platforms.evm6748' [1, 0, 0, 1345180490502]

---------------

At the moment I've no idea how to solve this. It might tke a while before I'm finished with the documentation to get it right.

Remco

First let me understand,

So you were able to update the platform and rebuild the platform correct?

Then when you went to build your CCS project which references the platform, it gives you error?

If this is the issue, I haven't seen this error myself so I will have to get someone to look at this or dig into it myself.  Meanwhile, is it possible that you could create your own platform that does what you want and build your project with that platform?

Judah

Remco,
somewhere after the error message you posted, you should be able to see in your console output another message that tells you how to convert that error to a warning. You need to add the following line to the end of your CFG script:
environment['xdc.cfg.check.fatal'] = 'false';

After you do that and rebuild, you should be able to check the map file and confirm that L3_CBA_RAM was used for both code and data.

Once you debug your problem with SYS/BIOS apps, you may want to go back and fix the platform configuration. Right now, the platform 'ti.platforms.evm6748' in your XDCtools installation is possibly corrupted because the new version of the platform updated some of the files in the platform package, while some other files are as they were in the old version. The best approach to avoid possible further warnings and errors is to create a new platform using Tools->RTSC Tools->Platform->New. When you do that, you'll be able to import 'ti.platforms.evm6748' as a base for the new platform, which will give you the configuration with code and data in L3_CBA_RAM. Save your new platform somewhere outside of XDCtools installation. Then use your new platform for your CCS project. Here is more help for using the Platform Wizard.

I thought turning that error in a warning was not a smart thing to do.

Doing so does makes the hello world example run, so it seems that the DDR is not correctly configured on the C6748LCDK.

I'm very new to this all, especially DDR, so how can I fix this? Is this something that needs fixing in the GEL file? If yes, shouldn't it be fixed for all C6748LCDK owners?

Regards,

Remco Poelstra

BTW, can I restore my original platform file by re-installing SYS/BIOS?

I don't know much about GEL files, so I hope someone else will answer that.
The original platform is a part of the XDCtools installation, so to get it to its initial state you would have to reinstall XDCtools. You would need to do that only if you are planning to go back to using 'ti.platforms.evm6748' with everything in DDR.

So are there any ideas or conclusions for why SYS/BIOS projects will not reach main() but DSP/BIOS projects work fine?

I don't know if it is useful additional info, but when I debug a SYS/BIOS project and hit the "Pause" button, it will break at some arbitrary address like:

No source available for "0x11806dfa"

Disassembly:

11806dfa:   A36A         [ A0]  BNOP.S1       0x11806DFA (PC+26 = 0x11806dfa),5
11806dfc:   E8108000            .fphead       p, l, W, BU, br, nosat, 1000000
11806e00:   028C0264            LDW.D1T1      *+A3[0],A5
11806e04:   61EF                BNOP.S2       B3,3
11806e06:   81C6                MV.L1         A3,A4
11806e08:   019526A0 ||         OR.S1         9,A5,A3
11806e0c:   01900274            STW.D1T1      A3,*+A4[0]
11806e10:   04041E29            MVK.S1        0x083c,A8
11806e14:   02808FAA ||         MVK.S2        0x011f,B5
11806e18:   0400E0E9            MVKH.S1       0x1c10000,A8
11806e1c:   E0400008            .fphead       n, l, W, BU, nobr, nosat, 0000010
11806e20:   038081AA ||         MVK.S2        0x0103,B7
11806e24:   01A00265            LDW.D1T1      *+A8[0],A3
11806e28:   02009029 ||         MVK.S1        0x0120,A4
11806e2c:   0200042A ||         MVK.S2        0x0008,B4
11806e30:   0200E0E8            MVKH.S1       0x1c10000,A4
11806e34:   03051E2A            MVK.S2        0x0a3c,B6
11806e38:   0300E0EA            MVKH.S2       0x1c10000,B6
11806e3c:   0210907A            ADD.L2X       B4,A4,B4
11806e40:   028CBF7B            AND.L2X       B5,A3,B5
11806e44:   73C6     ||         MV.L1X        B7,A3
11806e46:   A7E9                CMPEQ.L2      B5,B7,B0
11806e48:   20728121     [ B0]  BNOP.S1       0x11806F24 (PC+228 = 0x11806f24),4
11806e4c:   329802E6 ||  [!B0]  LDW.D2T2      *+B6[0],B5
11806e50:   02970F5A            AND.L2        -8,B5,B5
11806e54:   028CBFFA            OR.L2X        B5,A3,B5
11806e58:   1155                STW.D2T2      B5,*B6[0]
11806e5a:   003C                LDW.D1T1      *A4[0],A3

I don't know if any of that is useful, but I would really like to get the simplest of SYS/BIOS projects working. Is it just not supported on DSP-only projects?

Hi,

SYS/BIOS runs fine on a DSP only, but not from DDR. I hope someone from TI can shed some light on the DDR configuration, as nothing works from DDR at the moment (on the LCDK).

If you change the platform file to use internal memory then SYS/BIOS should run. Have you tried that?

Regards,

Remco

Remco,

Sorry to sound naive (I'm rather new to the entire embedded scene and CCS), but how do I find/edit the platform file? Is this within CCS or do I need to manually edit a file somewhere?

Thanks,

Charles

Hi,

In the post I did on Apr 02 2013 15:01 PM in this thread, I indicate how a modified the platform file.

There was an accompanying problem, which is worked around by a suggestion two posts later (suppressing the error). I suggest you do not edit the platform file as I did, but pick "New" from the same menu and use the existing platform file as a basis. Note that CCS has to be in Debug perspective for the Tools menu to appear.

I don't have access to CCS at the moment, so I can't be more specific for now.

Remco

No worries!

The problem was that I couldn't find where on earth the "Tools" menu bar was. The tutorial I was following for creating a platform package didn't show the step where they switched to the Debug Mode in CCS, haha.

I am now well on my way to creating one. Thanks much for your help! I have a feeling that this will solve many of my other problems as well.

Cheers

Unfortunately, I do not have or use DDR on my board, which is another reason why ultimately it would not have worked for me. Thanks to your help, I now have a SYS/BIOS project fully running. Hopefully, this will also help to solve some issues I was having with booting from my SPI Flash module. I had a feeling that something somewhere in my project believed that my chip was utilizing DDR, when in fact I had none.

Sorry I cannot be of any help with your DDR issue, but I greatly appreciate the help you have given me.