• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 101 subscribers
  • Views 2267 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.

How to build a simple NDK project for the TMDSEVM6678LE

Will Moore
Prodigy 160 points

Other Parts Discussed in Thread: TMS320C6678

I have been following the SPRAAX4 "Getting Started With the C6000 Network Development Kit" I have managed to get the NDK example client project to work on the TMDSEVM6678LE, however this uses the C code configuration method rather than the XGCONF graphical method of configuration preferred in SPRU523H "TI Network Developer's Kit (NDK) v2.21 User's Guide" and is not IMHO a good starting point for developing our own network application.  It would seem SPRAAX4 is somewhat out of date.  Ideally I would like to be able to configure from scratch a new project to run the NDK on the TMDSEVM6678LE using the XGCONF to which I could then add my network application.

While a colleague has been successful doing just that for the C6657 EVM, repeating this feat on the C6678 EVM is currently defeating us.  From here on when I refer to C6657 minimal NDK project and C6678 minimal NDK project I am referring to the minimal SYS/BIOS projects we have generated that use the NDK to run on the appropriate EVM as the basis for our network applications.

Details of our development environment:

TMDSEVM6678LE rev 3b

CCS 5.4.0.00091

MCSDK 2.1.2.6

MCSDK PDK TMS320C6678 1.1.2.6

NDK 2.22.3.20

SYS/BIOS 6.35.1.29

To generate the C6678 minimal NDK project I started by creating a new SYS/BIOS minimal project, then adjusted the SYS/BIOS configuration to include various parts of the NDK including EMAC, IP, TCP, UDP, DCHP CLIENT and Global Network Settings.  I added the platform_osal.c and resourcemgr.c files from the NDK example client project (setting a compiler pre-processor define for _LITTLE_ENDIAN as I am running little endian and resourcemgr.c had some code conditional upon _LITTLE_ENDIAN being defined.).  I selected "Use settings" for the following RTSC "Available Products": pdk_C6678_1_1_2_6/ti/drv/cppi, pdk_C6678_1_1_2_6/ti/drv/pa, pdk_C6678_1_1_2_6/ti/drv/qmss, pdk_C6678_1_1_2_6/ti/platform/evmc6678l, and pdk_C6678_1_1_2_6/ti/transport/ndk to get the project to build.  We had to increase the BIOS.heapSize in the app.cfg script from 0x0 in order to get the C6657 minimal NDK project to work and so did the same in the C6678 minimal NDK project - it is not clear to me why it could not be given some "sensible" default.

However while the C6657 minimal NDK project runs, uses DHCP to get an IP address and can be pinged, the equivalent C6678 minimal NDK project does not.  Rather I get the following console output:

"[C66xx_0] d begin

stack thread init

00000.000 NIMUIOCTL Failed with error code: -22

Service Status: DHCPC    : Failed   :          : 000

d begin

stack thread init

00000.000 NIMUIOCTL Failed with error code: -22

Service Status: DHCPC    : Failed   :          : 000

00000.000 NIMUIOCTL Failed with error code: -22"

It would seem that the NIMUIoctl() is returning -22 which I believe is EINVALID, an invalid parameter.  Since this is all TI code, I am at a bit of a loss as to what is missing.  Coupled with the fact that we performed almost identical steps on the C6657 EVM successfully this is a bit of a puzzle.

I have hooked into the stack thread begin hook, stack thread initialization hook, and network open hook and can see that these get run so the stack is being started, it just isn't working in the way the C6657 minimal NDK project "just does".

Any suggestions as to what is broken or what I have misconfigured would be appreciated.


 

  • 0
    Mastermind 6240 points

    Hi,

    You're right, this document is a bit old. Check these instead:

    http://www-s.ti.com/sc/techlit/spru523

    http://www-s.ti.com/sc/techlit/spru524

    The second link is to the API reference manual, you'll find documentation about NIMUIoctl on page 161

    And yes, it seems to be an invalid argument.

    Regards

    J

  • 0 in reply to Johannes
    Prodigy 160 points

    Thanks for the response Johannes.  As I mentioned in my original post, I have read SPRU523, and I was also aware of SPRU524 though I had not dug out the NIMU section.  Thanks for the pointer.

    I should say I started with SPRAAX4 because I believe this is still the TI recommended place to get started with the NDK, despite it being out of date.

    What I would really like is an up to date SPRAAX4 that tells you how to build a simple SYS/BIOS project including the NDK using the XGCONF tools.  This is not covered adequately anywhere IMHO and my attempts described in my original post fail to work.  As I said in my original post the NDK example client project is not IMHO a reasonable place to start for my own network application.  It is described in SPRAAX4 as something like a kitchen sink project i.e. everything is in it.  It also use C configuration of the NDK rather than XGCONF.  I want a simple starting point for me to add my stuff not a complex starting point from which I have to prune a huge amount of cruft to see the wood from the trees!

    I could dig deeper and find out why something that is automatically configured for me using XGCONF just does not work on C6678 but does on C6657 EVMs but I am not sure that I should have to.  Surely on an EVM it should be possible to achieve what I am trying to do with a few simple steps using XGCONF?  My guess is that it is related to the fact that the C6657 has just a EMAC driver but the C6678 uses resource manager, pa, cppi and qmss making it much more complex system to get running, perhaps beyond what is possible with the XGCONF system.  This is a real shame as SRU523 warns not to mix XGCONF with C configuration of the NDK but then there is no example of setting up the NDK with XGCONF on C6678.  So C configuration only I guess, and back to the kitchen sink client example, and I have not even started on the performance ... I will start a separate post for that!

  • 0 in reply to Will Moore
    Prodigy 160 points

    Please don't mark this question as answered, it is not.  Johannes was helpful, but nobody has suggested how to use the XGCONF tools to generate a simple NDK project for the C6678, which is what I was asking for.  Until they do, or TI state explicitly that is not possible and that for C6678 you have to use the old C configuration methods and base your project on the complex beast that is the NDK example client project, this question remains unanswered.

  • 0 in reply to Will Moore
    TI__Guru* 96960 points

    I forwarded this post onto the appropriate team.

  • 0 in reply to ToddMullanix
    Prodigy 160 points

    Thanks Todd, I look forward to the response.

  • 0 in reply to Will Moore
    TI__Mastermind 23525 points

    Will,


    The C6657 used the old internal CPPI descriptor mechanism, all the other Keystone I and II devices use the new Multicore Navigator setup.  As such they are not supported in the XGCONG utility.  You will need to use the c code examples from the MCSDK for configuration on these devices.


    Regards,

    Travis

  • 0 in reply to tscheck
    Prodigy 160 points

    Hi Travis,

    Thanks for getting back to me.

    So C6657 is the only Keystone I & II to support the preferred XGCONF configuration?  And the C6678 (with all other Keystone I & II parts) requires c code setup?  Hmm, that is disappointing.  The MCSDK examples are not a good starting point for a customer's application but it seems there is no alternative.

    Are there any plans to make XGCONF setup possible, or indeed to alter the MCSDK examples to provide a simpler, better starting place for a customer's application?

    Regards,

     

    Will

     

     

  • 0 in reply to Will Moore
    TI__Mastermind 23525 points

    Will,

    Not to my knowledge, but I will do some further internal investigation and let you know otherwise.

    Regards,

    Travis

  • 0 in reply to tscheck
    Prodigy 160 points

    Thanks Travis.

     

    Will