PRD used with NDK on C6748: Added PRD function not running

Which version of BIOS are you using?

What did you do to add the new PRD function?   Did you add it to your .tcf file using the gconf tool?  There's a property called mode which if set to "one-shot" requires you to call PRD_start() to make the PRD run.  And it will only run one time, until you call PRD_start() again.   If you set the PRD mode as periodic, it should run.

-Karl-

Hi Karl,

I am using BIOS 5.41.10.36 on a CCS 4.2 platform for a C6748 device.

I did use the gconf tool, and according to the mode setting we are using "continuous" not "one-shot". One thing I have noticed, is that the tool does not add lines to the TCF file that it (presumably) assumes to be default to the system. Would you expect that "one-shot" may be the actual default even though the tool shows "continuous" as checked off (but, not specifically entered in the TCF)?

Dan.

Hi Karl,

I guess I should have done this earlier, but I assumed since NDK was running we were OK.

It seems that "timer 1" indicated in the PRD (which I am assuming should be TIMER64P1DSP) is not incrementing. If this is the "Timer 1" referred-to in the gconf clock manager properties then it would seem that perhaps NDK can run without this periodic function operating?

TIMER64P0DSP (TIM34 segment) is running, but I'm not sure if this is actually "Timer 1" in the clock manager properties?

Dan.

Dan,

Can you please attach your *.tcf file?

The NDK cannot run without the 100ms PRD.  If you put a breakpoint in the function llTimerTick() you should see it hitting that function.  Can you try that?

Thanks,

Steve

1588.C6748_128M_RAM.zip

Hi Steven,

TCF file is attached. I am currently just linking the pre-built NDK libraries, but I will see if I can find a way to include just the file for llTimerTick() to see if a breakpoint can be set. I should also mention that we are using o3 level optimization so that may also prevent the ability to set a breakpoint on this PRD function?

Thanks.

Dan.

Hi Steven,

FYI:

For Timer 1 the TIM12RS and TIM34RS are "normally" 0 (in reset). If I try to enable them, I can enable TIM34RS, but something forces TIM12RS to zero no matter how often I try to enable it in the program. I am assuming this may have something to do with either the scheduler or something in NDK forcing this to stay off?

Dan.

Dan,

You won't need to add the source file in order to set the break point.  If you just type in llTimerTick in the break point manager, it will set it for you.  Similar for your PRD function.

Hi Steven,

I added the breakpoint, but the system did not stop. I was still able to connect on a TCP socket, send and receive data with no problem.

Dan.

Hi Dan,

I used your *.tcf file to rebuild the NDK helloWorld example.  I was able to put a break point at both llTimerTick and RawSend (I just made up an empty function called RawSend in hello.c).

The breakpoint hit for both cases and it seemed to work ok.  I've attached the .out file as well as my GEL file.

Can you first just try loading the .out file on your board and then see if you hit break points at llTimerTick and RawSend?

If you still don't hit those, can you then try to use the attached GEL file and then reload and try again?0361.hello.zip

Thanks,

Steve

Hi Steven,

Thanks for sending those files. I was not able to use your GEL file as it does not appear to initialize mDDR RAM on connect (maybe you use a menu item), but using my GEL file I could load the .out file you sent and successfully set breakpoints for both functions, and the HelloWorld DHCP and test connection was also successful.

Does this provide some additional insight?

Dan.

Dan,

DanB57495 said:

I could load the .out file you sent and successfully set breakpoints for both functions

Just want to make sure ... when you ran the program, did you hit the breakpoints at llTimerTick and RawSend?

Also, I forgot one part of the test.  There is a Windows side exe that goes with the helloworld app.  Once the board is running with the helloworld program, this Windows app can be run to connect to the UDP daemon.  It basically just sends the string "hello world" and then the UDP server on the board echoes that back to the app.

Can you try running this exe?  It's on my machine at the following location and should be similar for you:

C:\Program Files\Texas Instruments\ndk_2_20_04_26\packages\ti\ndk\winapps\helloWorld.exe

...

DanB57495 said:

Does this provide some additional insight?

Yes.  Since the helloworld example sets up a UDP daemon, and it appears to work on your same hardware setup, the next steps will be to firgure out why such a daemon server works for the simple case (hello world ex.) but doesn't work in your working application.

Steve

Hi Steven,

To clarify:

Yes, the breakpoints were hit.

Yes, the HelloWorld App ran.

Dan.

Hi Steven,

I started looking more closely at the Timer 1 registers and the plot thickens...

For Timer 1 on my code, something (presumably NDK) sets the GPINTGPEN, and GPDATDIR registers. On the Hello World .out you sent the values for these registers are 0x00000000, and 0x00000000. On mine they are 0x00030000, and 0x00030000 which sets the TM64P_OUT12 and TM64P_IN12 I/O pins to be used as GPIO. This makes sense since these lines are used to work the MDC and MDIO lines for the PHY.

What I found is that when these lines are set as GPIO, the timer does not run, but if I set these to 0x00000000, the timer runs, but the PHY program cannot setup the Ethernet. However, your Hello World does not seem to care whether these lines are used this way or not.

Any thoughts?

Thanks in advance.

Dan.