Compatible NDK version with DSP/BIOS 6.x

Hi Steven,

Sorry to be late in reply i was in vacation.

Thank t you for your prompt reply, a small note i want to mention that he main issue triggering my question that one of my college tells me that there is no NDK version compatible with BIOS6.xx , so i consider that there is a confirmation from your side that there is already a compatible NDK version exist .

Hi Steven,

Actually i need your help to understand some points not clear , I have porting task which is integrate NDK with WIFI stack and then port integrated solution stack (WIFI stack + NDK  integrated) to BIOS6 to run on ARM9 processor in OMAP L138 platform , i have the following questions which are :

1 - It is efficient to run BIOS6 on ARM9 ? , that is because from my basic knowledge in BIOS6 it is implemented to run efficiently on TI DSPs and i always use with ARM RTOS like linux, echos , threadx .... etc . I know that this is practically   possible to use BIOS6 with ARM but i cannot imagine is that reasonable or not , also is there are side effects that cause the RTOS to not operating efficiently.

2-  What is the NDK usage in this case from practical point of view ,i mean for example there is a certain services need NDK to work , also

3 -How can i integrate it with the WIFI stack

Sorry Steven for long description and thank you in advance,

Hossam

Hossam,

1. BIOS 6 is fully supported on the ARM 9.  Benchmarks are available and may be found in your SYS/BIOS 6.x installation.  For example, I see them on my machine here:

C:/Program Files/Texas Instruments/bios_6_31_03_25/packages/ti/sysbios/benchmarks/doc-files/Timings_Arm9.html

You can compare these ARM9 benchmarks with those of other targets, found in the same directory.

2. SYS/BIOS and NDK on the ARM could be used for an application that does not want the overhead of a higher level OS such as Linux.  For example, Linux has a long boot time compared to SYS/BIOS.  If you have a product that needs a fast boot time, SYS/BIOS would make sense over Linux in this case.

3. I'm sorry to say that you may be on your own on this one ... I'll double check with my managers to review our support standard on this sort of thing.

Hope this helps,

Steve

Many thanks Steven for your detailed reply, and please let me know if you got some info. regarding (3).

I just ran across this thread and am in interested in any info Steven finds for number 3 above also.

Our company is in a development using the OMAP L-138 and I am planning to use the ARM core using the NDK to perform TCP/IP to a host.  The DSP core will be quite busy doing signal processing.

I am using the latest releases of CC4.2, SYSBIOS6, and NDK2.20 on the Logic EVM and am trying to get the client example working on the ARM.  The example works on the DSP fine, and I did have it working at one time on the ARM, but now it quits working properly right after the "Registeration of the EMAC Successful" message on the console.  When I break it it's executing in nonexistent memory (it looks like an interrupt may be occurring that doesn't have an ISR tied to it).

I had come here looking for others using the NDK on the ARM core of the L-138 to help, but looks like there are very few of us.

Roy

Roy,

Are you seeing this problem with one of the NDK examples that is built for the ARM?

For example, the client example for the ARM is called: ndk_evmOMAPL138_arm9_client

If not, can you please try running the above example and see if you have this same problem?

Also, which *exact* version of the NDK 2.20 do you have?  We have made a couple of patch releases that fixed some problems for the stack when running on ARM:

http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ndk/ndk_2_20_03_24/index_FDS.html

examples may be found here:

http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ndk/nsp_1_00_00_09/index_FDS.html

Steve

Steve,

Thanks for the reply.  I am trying to run the examples you mentioned -- I have not modified them in any way.  Here are all the versions I am running on my Windows XP computer...

NDK:  ndk_2_20_03_24  (installed at  C:\ )

NSP:  nsp_1_00_00_09  (installed at  C:\ )

SYSBIOS:  bios_6_31_04_27  (installed at C:\Program Files\Texas Instruments)

XDCTOOLS:  xdctools_3_20_08_88  (installed at C:\Program Files\Texas Instruments)

CCS:  4.2.2.00033  (installed at C:\Program Files\Texas Instruments)

EVM:  ZOOM OMAP-L138 EVM from Logic PD

Emulator:  Blackhawk USB560M

And have the following environment variables set:
NDK_INSTALL_DIR=C:\ndk_2_20_03_24
NSP_INSTALL_DIR=C:\nsp_1_00_00_09

I have tried all 3 examples (ndk_evmOMAPL138_arm9_cfgdemo, ndk_evmOMAPL138_arm9_client, ndk_evmOMAPL138_arm9_helloWorld) and get the same results...

Using default MAC address
Using MAC Address: 00-08-ee-03-14-99
MAC Address = 00-08-ee-03-14-99
EMAC should be up and running
EMAC has been started successfully
Registeration of the EMAC Successful

...but that's as far as it gets.  I don't get any services starting like I do running the examlpes on the DSP core.  In my tracing of execution, what is happening is that something is causing a branch to address 0x00000018.  This is always the failure.

It happens in the function DHCPOpen() or NIMUIoctl() depending on if I'm single stepping or running to breakpoints I've set along the way during assembly debugging.  It looks to me like an interrupt is occurring causing the branch (possibly without a valid ISR assigned to it), and not normal program execution because it happens at different places in the code depending on how I'm tracing through the code.

Yesterday I rebuilt the NDK core using my versions of SYSBIOS and XDCTOOLS since the release notes said the distributed core supported versions of them that were lower than mine and got the same results.

 I have access to two EVMs and it works the same way on both (for whatever that's worth).  I can also run a standard Hello example (without the NDK) built from a CCS4 template on the ARM with no problems.  However, when I replaced the line BIOS_exit(0); with BIOS_start(); in that program, just now, I get  the same behavior -- it branches to to 0x00000018 -- maybe that's a clue?

Any suggestions you have would be appreciated.
Roy

Roy,

hmm... this is strange!  What hardware revision is your board?  I have a REV A board here.  I'm able to run the example OK.  One difference is that I connect via XDS560, not blackhawk.

Which GEL files are you using?  This could be related.

In fact, can you zip up your entire *built* client example project and attach it?  I would like to try running your exact exe here, as well as compare settings to what I've got here.

Also, please attach the GEL files you are using, too.

Thanks,

Steve

Steve,

The hardware revision on both the EVM and SOM are Rev A.

Here is my zipped project and gel files.  I got the gel files from the Logic website.

Roy

7651.ndk_evmOMAPL138_arm9_client.zip

Roy,

I was able to run the exe you sent without any issues.  I noticed that the GEL files I'm using are very different from the ones you sent.  I've attached the ones I'm using.  Can you give it a try with these GEL files?

Steve

5824.gel.zip

Steve,

I replaced my GEL files with the ones you sent, but still have the exact same problem.  You wrote in an earlier post that one difference between our setups is that I am running a Blackhawk emulator, while you are running a XDS560.  I wonder if that has something to do with it.

Do you know if CCS 4.2.2.00033 was verified using a Blackhawk?  I was up on the Blackhawk site and they mention CCS 4.0, but not 4.2.  I've been playing with target configurations thinking that it might be something there.  One thing I do see is that when I create a target configuration, I get a bug in the XML source for the ARM.  It's looking for me to add a missing "description="" " entry on the device line before it will let me save the configuration.  It didn't do that in an earlier version of CCS 4 that I was running.

I don't know what else to try...

Roy

Hi Roy,

Blackhawk supports all CCS v4 and later versions. This includes v4.0, v4.1, v4.2, v5.0, v5.1, etc. 

 I read through the post and unless I missed something, I don't think that this is emulator related - you can connect, load code and run fine.  I don't see how using SYSBIOS would be a problem (we have used this, XDC tools and the NDK with our Tailwind product).  I beleive it is related to the setup and configuration, but it may be more than just using the correct GEL files as Steve identified.  You may need to execute other GEL initialization fuinctions prior to loading and running your examples.  We find this to be the most common source of problems with OMAP targets.

Can you let me know the steps you are performing prior to running the code?  This should inlcude the what core you connect to first as well as any GEL scripts and functions that you execute.

Thanks,

Andrew

Hi Andrew,

I've probably tried many different connection methods, so I'll try to list all I can think of.  First, I configured the target connection as described in http://processors.wiki.ti.com/index.php/How_to_connect_to_the_OMAP-L138/C6748/AM1808_EVM_board_using_CCS%3F#XDS100v2.2C_XDS510_or_XDS560_external_emulator_-_DSP_.2B_ARM_.28OMAP-L138_SOM.29, changing the default JTAG TCLK Frequency and attaching the GEL files for both the DSP and ARM downloaded from Logic's site and also tried replacing those with the ones Steve posted.  I don't have any GEL file attached to the ETB11 and I haven't run any additional GEL initialization functions either.

1)  I've tried to just cycle power on the EVM and select Launch TI Debugger from CCS4, then connect to the ARM only and load the client program.  Then hit run.

2)  I've tried to  just cycle power on the EVM and select Debug Active Project  from CCS4 with the client project set as the active project.  Then hit run.

3)  I've tried to cycle power on the EVM and connect to the DSP core then select Debug Active Project  from CCS4 with the client project set as the active project.  Then hit run.

4)  I've tried to cycle power on the EVM and connect to the DSP core then select Launch TI Debugger from CCS4, then connect to the ARM and load the client program.  Then hit run.

5)  I've tried to cycle power on the EVM and connect to the DSP core and the ETB11 then select Launch TI Debugger from CCS4, then connect to the ARM and load the client program.  Then hit run.

You're right that I probably am missing other GEL initialization functions, but I don't know what they are.  Any information you can give me will be greatly appreciated.

Thanks,
Roy

Roy,

Ok.  Using your OUT file and the latest GEL files from this post, we were able to duplicate what you are seeing with both the TI XDS560 PCI card and our USB560 product.  This usually indicates that it is not an emulator problem.

After trying different scenarios, we found that if you issue the CCS menu command (  Target -> Reset -> CPU Reset(HW) ) after you connect to the ARM core and load the OUT file, the program runs as expected.  We saw this output:

Using default MAC address
Using MAC Address: 00-08-ee-03-14-99
MAC Address = 00-08-ee-03-14-99
EMAC should be up and running
EMAC has been started successfully
Registeration of the EMAC Successful
Service Status: DHCPC    : Enabled  :          : 000
Service Status: Telnet   : Enabled  :          : 000
Service Status: HTTP     : Enabled  :          : 000
Service Status: DHCPC    : Enabled  : Running  : 000
Link Status: 100Mb/s Full Duplex on PHY 0
Network Added: If-1:192.168.1.100
Service Status: DHCPC    : Enabled  : Running  : 017

Let me know if this works for you.

Andrew

Roy,

I hope the above suggestion worked for you.  If not, another idea I had was to try connecting the the DSP and loading the DSP side client example (instead of the ARM example) and to see if that works.

In any case, do let us know where you're at with this issue.

Steve

Guys,

SWEEEEET!!!  Andrew's suggestion did the trick!

But that does ask the question -- Is this just a temporary workaround for a GEL file problem that will be addressed in the future, or is this the way I'll always have to start?

At least I can move forward with my development work for now.

Thanks to you both!
Roy