DM648 Ethernet Packet issue with NDK 2

Depp,

As you've discovered,  it is true that the NDK's packet buffer manager is limited to packets of 1500 bytes.  The only way that I know of to increase this limitation is to enable jumbo packets.

Is there a specific reason why you do not wish to use the NDK's jumbo packet feature (which should remedy this problem)?

Steve

Thanks for reply

Actually in my custom application i use some packets of exact 1500 bytes size which are transmitted but generated message log of emac send returned error.

I also have a issue which i would really appreciate if u ans. I use Hello world application and when i load the code and run it halts as i wrote earlier " i have to load my code twice to run the application in ist attempt CCS halts at Hello World Application TC/IP Stack MAC Address **-**-**-** ", but if i load the code and run it and then plug in 2 lan cables in both RJ45 then the application runs fine.

Mark,

I'm not sure I understand what you're doing with the cables.  So it sounds like you are loading + running the program, and there are no Ethernet cables plugged in, and that's when you see this problem?  Then, if you plug the Ethernet cables into the board, it all works fine?  Is this correct?

Steve

Steve,

Actually it is the other way, when I load and run the code without the Ethernet cables plugged in it works fine. But if the Ethernet cables are already plugged in and I try to load the code and run it then the CCS halts after printing the two messages I already mentioned in this scenario I have to reload the code and run again (in 2nd attempt it works fine). Please guide me how I achieve 1st time successful loading and running the code when the cables are already in RJ 45 jack.

Mark

Waiting for the reply.

Mark,

I think I am able to reproduce your problem, however what I'm seeing looks to be independent of whether or not the ethernet cable is plugged into the board or not.

I see that on the first run the example works fine, but  on the 2nd run of the helloworld example program on the EVM DM648 (built for NDK 2.00 with DM648 patch applied, and BIOS 5.41.03.17), the output only shows:

TCP/IP Stack 'Hello World!' Application

Using MAC Address: 00-0e-99-02-aa-23

But this is as far as it gets. However, if I reset/reload/run at this point, it works.

So, the pattern is like this: the first time I run, it works ok, but the second it hangs with above output, the 3rd time it works, then 4th time it hangs again.  So, it seems that it only is working every other time.  Is this the same behavior you're seeing?

Also, I am seeing this with the network cable *always* plugged into the board (cat 6 cable attached to a 1Gbit Netgear switch).  Do you think it could be possible that the cable plugged / unplugged scenario you saw was just coincidentally aligned with the "every other run" cycle I'm seeing?

---

Now for the good news.  I also built the helloworld example against the latest NDK release - NDK 2.20.02.22 - and I *do not see this problem*.  The example runs fine after about 10 run/reset/reload cycles and gets an IP address each time and I'm able to ping the board.

I've attached the working helloworld example executable to this thread, but I think you are using a custom board with a DM648 processor, so this may not work for you.  Please let me know if that's the case. (NOTE: the attached had to be renamed to extension ".txt" as ".out" is not allowed to be posted.  Please rename the attached to have the .out extension)

7658.helloWorld_NDK2_20_02_22_dm648_patched_bios5.41.03.17.txt

Steve

Steve

Thank you for detailed reply, I am unable to download the NDK version 2.20.02.22 however I have downloaded the NDK version 2.20.00.19 and now looking to implement the project on it. Kindly send me the link from where i can download the other version. I searched alot on the ti website but cudnt find the link.

Mark

Mark,

My apologies, the 2.20.02.22 version isn't currently available on the download page.

However, you should be fine using NDK 2.20.00.19.  The updates in the 2.20.02.22 version are minor patch fixes which are not related to the DM648.

In any case, I'll get the download page updated with the latest and let you know once it's ready.

Steve

Steve,

Thank you for the help. I ran the .out file you provided on my EVMDM648 board. It ran perfectly with no reloading issue. But the problem is when I downloaded the NDK 2.20.00.19 it does contain HelloWorld application but it has no .pjt file for that only a HelloWorld.c file and a HelloWorld.exe file is available. Where as earlier I am using HelloWorld application on EVMDM648 and on my custom board with NDK 2.0 DSP/BIOS 5.31.07 in ALE Bypass Mode with CCSv3.3 it had HelloWorld.pjt with complete project.

I want to know that what I do? either I change my .pjt file for NDK 2.0 such that it becomes compatible with NDK 2.2.00.19 or I wait for the release on NDK 2.2.00.22 because the .out file you sent showed identical behaviour to that of HelloWorld Application of NDK 2.0 this made me presume that NDK 2.2.00.22 has complete project file for HelloWorld Application.

Also tell me that when will be NDK 2.2.00.22 available for release.

Regards,

Mark

5756.helloworld_220.pjt.txt

Mark,

Ok, this is good news.  But, you'll have to update your project.  I'll give you some tips on how to do that.

The NDK 2.20 has undergone some design changes when compared to the 2.0 version that you have.  One of these changes is the restructuring of the examples, which are now included in the seperate NSP product (NDK Support Package); for the 2.20 release, we only supported an NSP product for the evm6748 hardware (so, there are also no projects in the 2.20.02.22 release).  But, if you are curious, you can find the NSP 1.00.00.09 for the evm67487180.helloworld.pjt.txt for download on the NDK download page - http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ndk/index.html.

However, all of the previous NSPs (including the DM648 one that you have) are still compatible with a little bit of tweaking.  Also, the 2.20 release is meant primarily for CCSv4.x, but you should not need to worry about this, as all you would need to do is link the core libraries of 2.20 into your existing project.

I've attached the helloworld project that I updated in order to build it using the NDK 2.20.  I've also attached the original project, so you can diff the two  to see what exactly has changed between them.  Notice that I have the following environment variables defined, which the project uses to point to the appropriate libraries.

NDK_2_00_INSTALL_DIR = C:\Program Files\Texas Instruments\ndk2.0.0_source

NDK_INSTALL_DIR = C:\Program Files\Texas Instruments\ndk_2_20_02_22

One other thing that's different that you don't want to miss is that a couple of library names have changed.  Since you're using DSP/BIOS 5.x, you should be aware of these name changes; you'll want to make sure that you use the 'bios5' flavors:

1. os.lib --> os_bios5.lib
2. hal_timer_bios.lib --> hal_timer_bios5.lib

The NDK 2.20 should be on the official product download page by early next week.

Steve

Steven

Thank you I have understood  most the points and right now I am downloading CCSv4.2. I will try to implement it with EVMDM648 DSPBIOS 5.x and NDK 2.2.00.19 till the time didnt get the latest NDK. I will inform you soon about the success or failure of my try to update the project from NDK 2 to NDK 2.2.

Regards

Mark

Steven

I started using CCSv4.1.2 but is still unable to link NDK 2.2.0.19 with it. Plus as u mentioned earlier latest NDK 2.2.2.22 is not available for download uptil now. Meanwhile i got a forum reply from Mark Grosen the TI employee where he rejected the idea that NDK is the cause of this halting coming in alternative running/loading. I and posting here what he said and i want your opinion because it really matters for me. He replied the below post with reference to the same problem i discussed with you.

Mark Grosen posted:

One idea: insure you do a device HW reset before reloading and running. If you run a program, interrupts are enabled. If you then just reload the program without resetting, an interrupt can go off (typically from the EMAC) before the software has been initialized, which can cause a crash (typically ending up in UTL_halt). In a real embedded product, each time there is a reset, the CPU is reset and interrupts are disabled. That is not happening when using the debugger unless you do it manually.

Hi Mark,

What is the exact problem you are having with linking the libraries of the NDK 2.20.00.19 release?  Are you getting errors in your project?  If so, please post the errors.  Also, were you able to diff the two project files I sent, to see the necessary modifications?  Just let me know and I can try to help.

As far as the reply from Mark, he's actually out of town right now.  I'd like to discuss this with him.  When I looked at your problem, I was able to reproduce it, and then saw that when I built with the latest NDK , the problem was no longer present.  I believe that I was able to load/reload/run the working program without power cycling, however.

Steve

Steve,

Right now I am doing some other paper works relating to project but I am sure that after 2 or 3 days i will be giving you my success story (I am pretty sure that the information you provided will make NDK 2.20.00.19 to work with my application and CCSv4). I am also keenly waiting for your post after your discussion with Mark Grossen. Meanwhile I want to tell you that my goal is to make standalone application in which the code will run in boot mode from the NOR flash. I was thinking that the multiple try on RUN/LOAD/RUN issue with NDK is causing my boot mode to only work correctly after multiple tires of powering the board on/off. But now after Mark Grossen's comment I am of the view that the multiple try issue with the boot mode is not due to that NDK 2.0 bug but something else may be because my code is interrupt based and GEL file is not loaded in bootmode or something else.

I load the helloworld network application code in nor flash using AIS utility and the custom board as well as EVM board only works correctly with multiple tries of powering the board on/off. And in boot mode there is no set pattern unlike in emulation mode where alternative tries worked.

Just wanted to clear my mind that I am behind the right fish or need to correct my target. Your reply will be appreciated.

Regards

Mark

Mark,

I actually don't have much experience with flashing a program so that it runs at boot time.  However, there are others here that do know about this.

What I can say is that the GEL scripts do a lot of memory initialization and other configuration, and when you're running out of flash in boot mode, the GEL script is not used.  So, you have to ensure that the same functionality that's done in GEL is done in some initialization function in your C code.

Mark's out of town right now, so he's a little hard to get a hold of, but I'll talk to him about your concerns as soon as I can.

Steve

Steve

I tried my best to run CCSv4 and was indeed successful. I also successfully linked BIOS and NDK 2.2 but there is some problem in building my HelloWorld application.

I also loaded the .out file you sent to me earlier using CCSv3.3 and it ran perfectly with no halting or double load/run issue. I just want a help so that I will be clear that what exactly is the problem. Can you please send me that whole project folder in zip file so that I can run it on my board with CCSv4.? I am refering to that project folder which you only created for me to check my issue. I mean HelloWorld application with NDK 2.2, BIOS 5 and CCSv4 running on EVMDM648. I will be very greatful to you because if it runs perfectly then I will simply replace you HelloWorld.c file with mine to get me out of this trouble.

Looking forward for you reply.

Regards

Mark

Mark,

I've attached the project I updated to use the NDK 2.20X libraries (zip file renamed to have .txt extension...)

2134.helloWorld.zip.txtNote that it's in a directory called "helloWorld".  You should be sure to back up your existing helloWorld examples directory (e.g. rename it) then copy the attached on into your NDK examples directory in place of the original one (again, please back up the original directory!)

Notice that you'll need to define environment variables to point to the NDK 2.20X release (for the libraries) as well as the NDK 2.0 release (for the example sources, e.g. client.c, etc.).  You'll also need the BSL for EVM 6748 (if you don't already have this it can be found on Lyrtech's website).

Here's the values of these environment variables for my machine.  Note you'll just need to modify them so that the paths are correct for your machine:

>echo %NDK_2_00_INSTALL_DIR%
C:\Program Files\Texas Instruments\ndk2.0.0_source

>echo %NDK_INSTALL_DIR%
C:\Program Files\Texas Instruments\ndk_2_20_02_22

>echo %BSL_EVMDM648_INSTALLDIR%
C:\Program Files\Texas Instruments\Lyrtech\EVMDM648\BSL

For NDK_INSTALL_DIR, you should be fine using the NDK 2.20.00.19 version that you have right now.   There are no changes that would affect you between the 2.20.00.19 and 2.20.02.22 builds.

I hope this helps you out.

Finally, I will be on vacation for 2 weeks starting tomorrow, and will not return until January.  I will not have email access at this time, so I will not be able to respond to your forum posts during this time.

However, please continue to post and others on the team will do their best to continue to support you.

Thanks,

Steve

Steve

Thank you, I have got the zip file and will try to work everything out as you return from your vacations.

Enjoy yourself.

Merry Christmas in advance.

Regards

 Mark

Hello Steve

I  guess your are back from your vaccations.

I tried all my best to run the project you send as well as mine with CCSv4.1.2. However i was able only to run non RTSC project with EVMDM648. The reason is that during compiling of RTSC projects the error comes that CCSv4.1.2 with NDK2.2 is unable to recognize UINT8 UINT16 and UINT32 data types where as that was possible when i was using CCSv3.3 and NDK2.0. However in the mean time i got another solution nearly working to kill my double load issue out. If i clean my whole DDR from the address 0xE0000000 to 0xEFFFFFFF and then load the out file of my hello world application runs fine with no double load issue. This implies that the double load issue is coming due to some random value present at any unknown location of DDR.But i cannot combine DDR cleaning code with helloworld code as it will cleant the loaded project code out leaving me at the starting point of problem. therefore only way  right now is to alternatively clean the DDR and then load the project to run it in the ist attempt. Can you please help me out why the garbage or random value present in the DDR is creating this double load issue as for standalone application i have to sort it out. 

Regards

Mark

Hi Steve,

It looks like this project is set up for CCS v2 ... is this correct? I am unable to import it into CCS v4.

Thanks, peter

Hi Mark,

So you are again seeing the problem in which you have to perform the double load?

I was reviewing the thread posts from last month, and I remember that I had sent you an example executable that was built with the latest NDK, and that you reported that with this executable, you *did not* need to perform the double load.

Then, you re-built your app using the latest NDK, and you are still seeing problems without doing a double load?  Is that correct?

Also, what happens if you power cycle the board in between each load?  Can you try this and let me know the result?

1. power off the board

2. power on the board then connect to the board in CCS

3. load the program

4. run - does it work?

5. halt the program

6. disconnect the board from CCS

7. power off the board

8. power on and connect in CCS

9. load/run - does it work?

Steve

Hi Steve,

1st of all i answer your method

1. power off the board-----------------------ok

2. power on the board then connect to the board in CCS----------------------ok

3. load the program--------------------------------------------ok

4. run - does it work?-------------------------------------------ok/ yes it works

5. halt the program-----------------------------------------------ok

6. disconnect the board from CCS-----------------------------------------------ok

7. power off the board-----------------------------------------------ok

8. power on and connect in CCS-----------------------------------------------ok

9. load/run - does it work?-----------------------------------------------ok/ yes it works

I never said that double load issue was solved at my end. I just mentioned earlier that i have shifted from CCSv3.3 to CCSv4 just to run NDK 2.2 to solve double load issue.

But i was not able to run mine as well as your project with CCSv4. I could only make non-rtsc projects work with CCSv4.

Hence the double load issue still exists. Basically i want to make my project run in standalone boot-mode and i have to give it multiple power on/offs cycles to make the code running from NOR flash and to my understanding the reason is that double load issue in emulation mode also makes program stuck in NOR boot(i dnt knw i m correct here or not).

So i guess now you might help me better with more light drawn on the issue.

Regards,

Mark

Mark,

Sorry it took so long to get back to you, it seems that I just have too many people to help these days!

Ok, I'm investigating this issue now.  In doing so, I've ported over the evm6748 helloWorld CCSv4 project to build for the evmDM648.  I've attached it to this forum post.

A couple of things ... first off, please ignore theproject  name.  It contains the string "evm6748" in it; that's just because I ported the project from the 6748 one, and CCS doesn't let me change the project name.

Second, the project uses some environment variables.  You should define them in your build environment then restart CCSv4.  Here's the values in my setup:

1. NDK_INSTALL_DIR = C:\Program Files\Texas Instruments\ndk_2_20_03_24
   1. this is the path to your NdK 2.20 installation.
2. OLD_NDK_INSTALL_DIR = C:\Old PC\NDK_dm648_patch_test\ndk2.0.0_source
   1. path to the NDK 2.20 installation which has some DM648 drivers, etc.
3. BSL_INSTALL_DIR = C:\Program Files\Texas Instruments\Lyrtech
   1. location you installed the BSL from Lyrtech

Once you define the above, start CCsv4 (if it was already open , you'll need to restart it).  Then, you can go to the menu "Project -> import existing CCS/CCE Eclipse project".

Choose "select archive file" then browse to where you saved the attached project.  Rebuild and run.

Regarding the problem in which every other load fails to run, I'm able to reproduce that problem here.  I see that in the fail case, a SYS_abort is happening in the ECM module (the ECM module is directly related to hardware interrupts, so I suspect what Mark mentioned before, about interrupts being ready to run from the previous program, may be correct).

I'll respond back once I know more.

Steve

6204.dm648_ndk_helloWorld_CCSv4.zip

Steve

OK Thanks but would you please confirm that this project use send me for CCSv4 has double load issue solved?

Regards

Mark

Sorry if you have already done so, but can you please explain with as much detail as possible the symptom of the failure for the 2nd load?   I think you are in abort?   Can you send a screen shot with registers visible and also where the program counter is on the 2nd failure (show 10 instructions at least before/after the PC)?   I discussed with Steve yesterday and I suspect that an interrupt is being enabled before the ISR has been plugged.  This is just a wild guess, but would be useful to look at the 'IRP' register and see where it points in the code.  It should be a clue.  The IRP points to the return address of the ISR.  If my theory is correct, it should point back to a place where IER is being enabled just prior to the Hwi_dispatchPlug() or ECM_dispatchPlug (or whatever) APIs are called.

Thanks,
-Karl-

Steve

Thanks, OK I got your point but what about the actual int main() function code of helloworld.c? do i write your code on top of int main() in helloworld.c or i have to remove the contents of existing int main() and write it in some other function.?

Regards

Mark

Mark,

Apologies for the confusion, I could have been more clear.  You should be able to just add that ECM code to what already exists in main().  Please see below and let me know if you still have questions

//---------------------------------------------------------------------

// Main Entry Point

//---------------------------------------------------------------------

int main()

{

    /* keep existing variable declarations here, adding ECM variables after */

    /* ... */

    ECM_Attrs ecmattrs = ECM_ATTRS;

    ecmattrs.unmask = 1;

    /* keep existing code here, adding ECM_dispatchPlug() call after */

    /* ... */

    ECM_dispatchPlug(32, (ECM_Fxn)(&ndk_helloWorld_nop), &ecmattrs);

}

Steve

I tried to implement the code as u told me to do so but got the following errors CCS says that ECM_Fxn ECM_Attrs and ECM_ATTRS are undefined.

Please tell me where i am wrong. I am using NDK 2.0 with CCSv3.3 and BIOS 5.

Mark

Mark,

You need to include the header file for the ECM module:

#include <ecm.h>

Steve

Steve

Thank you very much the issue finally resolved the double load has ran and i hope it doesnt appear again. I tested and evaluated alot and came to the conclusion and it is solved now. I also marked your answer as verified.  I also had a question regarding DSP BIOS training but i posted it as a new question(plz respond to that) so that this thread do not prolong unnecessarily.

Thanks again Steve

Regards

Mark