• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 99 subscribers
  • Views 1417 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.

NDK "NO PHY CONNECTED" while executing own project

Rico Schulze
Intellectual 480 points

Other Parts Discussed in Thread: TMS320C6747, OMAP-L137

Hello
 
I have implemented a task which is based on the audio sample of the PSP into the client-sample of the NDK. To do so i have changed the ethdrivers.c like mentioned in the FAQ.
If i suspend the network-task, my audio-processing Task works fine. iIf i try to run both, i am getting the error Message "NO PHY CONNECTED" via stdout, and i suppose the amount of cycles needed for printf() avoid that my audio task executes well.
 
Everytime i run my project, that includes my Audio and NDK-task i am getting the Message "NO PHY CONNECTED". After i run my project once, NO OTHER NDK-Project is able to access the Network, i am always getting the Error "NO PHY CONNECTED" !  This error does only disappear if i end the CCS-processes and power down the board. After this, the samples work correct again. but if i run my own project again, all network-functionality fails, until i power down the board again!
 
could you provide me with the a reason for this, and a possible soultion?
(i am using CC v3.3 to program the dsp-side of the OMAP L137 TMS320C6747 Board )
 
best Regards
Rico
  • 0
    Intellectual 480 points
    If i use the Main of the Audio-sample
     
    Void main(Void)
    {
        // power on the Mcasp 1 instance in the PSC  
        configureAudio();
        // enable the pinmux for the mcasp device   
        return;
    }
     
    the Error already occures !
     
    the Problem seems to be the call of the function configureAudio(); 
    Deleting this call in the main, of course prevents the audio from working correct, but allows the server to work, if both tasks are performed. If the Stack-test()-Task is not performed, audio processing works even without calling configureAudio();     !
     

    I already read some postings, dealing with the pinmux-registers. And because they are configured within the configureAudio();  I probably have a problem with that, but i am not sure how the pinmux would have to be configured to solve it.

    best regards

     
    Rico
  • 0 in reply to Rico Schulze
    TI__Mastermind 30915 points

    Rico,

    You need to debug further by including the PSP audio src code to see what the configAudio() fct does.
    For example check how Pinmux11 register is configured as it is used for mulltiplexing both EMAC and McASP1 pins.

    The following document should help to configure the pinmux registers for the C6747 EVM accordingly:
    a) C674x pin multiplexing utility (sprab06a):    
    http://focus.ti.com/docs/prod/folders/print/tms320c6747.html
    b) OMAP-L137 EVM tech reference and schematics:
    http://focus.ti.com/docs/prod/folders/print/tms320c6747.html

     

     

    A.

  • 0 in reply to AnBer
    Intellectual 480 points

    I have changed the audio_evmInit.c - File which is placed in the src-directory. That src-directory is in the same directory like the Audio_evmInit.h -File that my project includes (I am telling this so especially, because it does not seem to take effect)

    and did this like following:

    #define PINMUX8 (*((volatile Uint32 *)0x01C14140u))

    #define PINMUX11 (*((volatile Uint32 *)0x01C1414Cu))

    #define PINMUX12 (*((volatile Uint32 *)0x01C14150u))

    #define PINMUX10 (*((volatile Uint32 *)0x01C14148u))

    #define PINMUX9 (*((volatile Uint32 *)0x01C14144u))

    #define PINMUX18 (*((volatile Uint32 *)0x01C14168u))

    #define PINMUX13 (*((volatile Uint32 *)0x01C14154u))

    and within the configureAudio-function:

    PINMUX8 = 0x01122000u;

    PINMUX11 = 0x11100022u;

    PINMUX12 = 0x11111111u;

    PINMUX13 = 0x00111111u;

    PINMUX9 = 0x00200000u;

    PINMUX10 = 0x22222220u;

    // PINMUX18 = 0x44400040u;

    I did this according to the small program "Pin Setup" with EMAC,  McASP1 and I2C0 beeing enabled for the OMAP-L-137 - Device.

    I also tried to configure the use of McASP1 and I2C0  and McASP0, because someone told me to try this, that is why PINMUX18 was configured once. but wether the configuration you see above, nor the one using PINMUX18 were able to let the board "see it's PHY"

    I also added this file to my project, but the wanted effect still does not apply.

    Configuring EMAC,  McASP1 and I2C0 AND McASP0, would cause a collision, according to the pin-Setup-software, so i am not shure what i should try ...

     

     

  • 0 in reply to Rico Schulze
    TI__Mastermind 30915 points

    Rico,

    At the device level:
    Yes, McASP0 and EMAC pins are mutlipxed. So you should use the EMAC + McASP1 + I2C config from the Pinmux utility.

    At the board level:
    - Also double check at the board level if some specific HW setup are required. It could be that some special settings are needed.
    information should be available at the SD web site:
    http://focus.ti.com/docs/prod/folders/print/tms320c6747.html

     

    BR,

    A.

  • 0 in reply to AnBer
    Intellectual 480 points

    If i use McASP1 I2C0 and EMAC, and run both tasks, with a periodic function calling yield() to switch between the tasks, i am not getting the "NO PHY CONNECTED" message, but none of the tasks works as expected..

    if i run the audio task while the NDK-Task is given priority -1 (so it is not executed) Audio works fine.

    The other way around (Audio-priority -1 and running NDK-Task only) the network-functionality still is not available.

    What i do not understand, is that deleting every PINMUX-instruction within the configureAudio()-procedure (or deleting her call within the main) allows both tasks to work as they should, but only, if they are performed alone, with the other task beeing suspended by giving him priority  -1.

    So i believe that the general configuration should be correct, if that is what you wanted to say with "Board-Level".

    Is there also a procedure configuring the PINMUX called by the NDK, that would have to also be reconfigured?

    by now i have no idea how to let both tasks work together ...

     

  • 0 in reply to Rico Schulze
    Intellectual 480 points

    according to the PIN SETUP-tool we configured the PINMUX-registers to make use of EMAC, McASP1 and I2C0.
     
    If we run our project, with the audio and the network task, none of them functions. (but the "No Phy connected" warning disapeared...)
    Running only the audio-task (giving the NW-Task priority -1) results in the audio task to perform as supposed.
    Running only the network-task (giving the audio-Task the -1 priority) does not result in the network to be available. (But the error "No Phy connected" does not occure)
     
    If i do not configure the Pinmux-registers in any way (deleting the call of configureaudio() in the main) both tasks are performed as wanted, if they are executed alone( with the other task having priority -1) , but do not work if performed together (in that case network works, audio not) .
     
    Because of that, i took a look at the PINMUX-register-values.
    While running only the audio task and also while running only the network-task (wich both results in the correct execution) the PINMUX registers are like followed:
     
    PINMUX8   = 21122111
    PINMUX9   = 11011112
    PINMUX10 = 22222221
    PINMUX11 = 11112222
    PINMUX12 = 11111111
    PINMUX13 = 22111111
     
    (performing both tasks together results in the network to function, audio fails to work properly - but the PINMUX- registers are the same like shown above)
     
    What i really do not understand is, that according to the "Pin Setup"-Tool, configuring EMAC causes a change in PINMUX9, PINMUX10 and PINMUX11.
    The Change in PINMUX9 is supposed to be: 
     
                   xx2xxxxx              (with x representing a "Do not care" / beeing configured for the use of other peripherals)
     
    So i think that using EMAC would need a 2 at the third position of this parameter.
    As you can see above, if i run a project that performs network well (and to do so it needs EMAC i think) my PINMUX9 does not contain that 2 at the third position.
     
    If our project would be able to run both tasks at the same time, i would not care about things like that, but this avoids me to understand the PINMUX-issue properly.
     
    I also took a look at the documents available from Spectrum Digital but they do not refere to something like PINMUX, I2C or McASP. (only that I2C and McASP1 are used for audio-purposes) 
     
    I am pretty sure that i am having a PINMUX-problem, but could the not-performing of one task also be a priority-issue, if i am yielding between them using a periodic function calling yield() ? Studying the web i saw several advices to run the NDK-task (not sure if they ment the one "Stack-Test"-thread, which starts the different servers, or the serverthreads themselves) on a high priority.
     
     
    If i do not configure the PINMUX-Registers, the audio-processing-task (wich is a little modificated version of the psp-audio-sample) gets stuck performing the following code-sequence:
           
           nmadus = SIO_reclaim(inStream, (Ptr *)&rcv, NULL);        
    while the network task continues to run.
     
    So what PINMUX configuration would allow both of the tasks to work together?...
    (configuring them to what the PinSetup-tool says, causes both tasks not to work together, not configuring them allows at least the network-task to function, so could the tool be wrong? or would i need something else than EMAC McASP1 and I2C0 ?)
     
    Or does getting stucked performing SIO_reclaim refer to another possible problem?
     
    best Regards
    Rico

  • 0 in reply to Rico Schulze
    Intellectual 480 points

    What i forgot to mention, is that configuring the PINMUX-Register like advised by the Pin_Setup -Tool but changing PINMUX9-Register to be 00000000, causes the same effect like not configuring the registers and using the "default"-Values inside them (like shown in my previous posting)

    Both tasks are performed if the other task is suspended by giving him Priority -1, running both tasks results in the Audio-Task not to be able to perform Sio_reclaim().

    could someone provide me with the correct pinmux-configuration to run both? Or at least give a hint to find it?

    i also wonder if a possible reason could be, that i am aditionally using the LED and DIP_switches of the board, but this used to work fine with audio all the time..

     

    best Regards Rico

     

  • 0 in reply to Rico Schulze
    TI__Mastermind 30915 points

    a) Just to clarify some points:
        - TI literature is device centric (ie specifically talks about the device)
        - Spectrum Digital literature is about an example of implementation of the OMAP-L137.
    It is important to check both.

    b) I compared the Spectrum Digital (SD) schematics and the TI documents.
    I have seen that SD is not making use of the internal 50MHz CLK src for the EMAC. The pin mux utility assume the use of the internal 50 MHz (coming from SYSCLK7).
    See page 78 of system rference guide - sprugm7d and page 24 of the SD schematics:
        http://support.spectrumdigital.com/boards/evmomapl137/revg/files/EVMOMAPL137_Schematics_revg.pdf
    If you use the default PINMUX value from the pinmux utility for the EMAC then the EMAC might not function.

    The pinmux settings to be used with the EVM specifically can be found in the DSP GEL file:
        http://support.spectrumdigital.com/boards/evmomapl137/revg/files/evmomapl137_dsp.gel
    It is almost what you use.

    c)     It might make sense to check at run time what are the pinmux values. I am not sure but it could be that the EMAC driver used for the TCP IP stack does configure again the pinmux values during some init phase.

    Take each example separately. Initilaize the DSP via the GEL file and check in main and in the TSK that the pinmux values have not been altered.

    Both example (Audio and TCP IP) should work separately with the pinmux done in the GEL file. When it is the case you can merge the two.

    d) SIO_reclaim() is a blocking call. It means that if no buffer has been made available by the driver then SIO_reclaim() will block forever. Typically the ISR of the peripherals used by the driver will deal with new buffers and will make a call to the according API that in turn will unblock SIO_reclaim.
    It seems like the ISR is not called. You might need to look at the complete chain from the McASP RCV to the ISR generation to understand why no ISR is generated.