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.

RTOS/AM3356: Profinet Slave v1.00.02 issue

Part Number: AM3356
Other Parts Discussed in Thread: AM3359

Tool/software: TI-RTOS

Hello,

Today I downloaded the V1.00.02 version of the PROFINET SLAVE,  PROCESSOR-SDK-RTOS 04_02_00_09  and CCS 7.3.   I then patched the PDK,  rebuilt the PDK and created the AM335x IRT project,   I was then able to successfully load the project into CCS7 and build.

To confirm that the installation and build were good,  I then loaded the APP file (release directory of the project) to the microSD for the AM335x ICE BOARD.

When I applied power to the AM33x ICE BOARD I observed that the board did not come up the way I was expecting -- specifically that there was no scrolling information on the small display.      I also tried to ping the board and did not get any response.

I then replaced the APP on the microSD card with the prebuilt APP for V1.00.02.    I observed the same results as with the APP I had built --  the AM335x ICE BOARD appeared to be non-operational.

Finally I replaced the APP on the microSD card with the prebuilt APP for V1.00.00.    This time I observed that the board was operational:  there was scrolling information on the small display and the board responded to a ping.

Should I expect the prebuilt APP for V1.00.02 to function similarly to the prebuilt APP for V1.00.00?

I am not sure if this is related to the problem above,  but when I attempt to use the CCS7 debugger to try to debug the problem I get a "CORTEXA8: UNHANDLED ADP_STOPPED EXCEPTION 0x20023" error.

Any help would be appreciated.

Mark

  • The RTOS team have been notified. They will respond here.
  • Mark,

    Have you also updated the MLO in your SD card? The MLO (renamed from bootloader_boot_mmcsd_a8host_release_ti.bin) is available from pdk_am335x_1_0_9\packages\ti\starterware\binary\bootloader\bin\am335x-evm\gcc.

    Let me try if the exception with .out file can be reproduced in my setup.

    Regards,
    Garrett
  • Hi Garrett,

    Thanks for the quick response.  

    No I did not update the MLO,  

    I just updated the MLO and tried --- it is now working as expected.   I guess I was thinking that the MLO was a "low level" boot loader that would not have changed between versions of the PDK.

    Still not sure why I was getting the problem on load of the program into the debugger.   Hopefully you will find a similar easy answer!!

    Regards,

    Mark

  • Hi Garrett,

    I am no longer concerned about the debugger issue I was having with the ICE board.    I started the port of the newest version and had no debugger load issues when loading onto my board.

    I would like your recommendations on where to best disable one of the PHY's.     My functional requirement is that only one of two ETHERNET ports be active at a time,  and a jumper that is read during initialization determines which is active.      I was planning to isolate one of the PHY's based on the state of the jumper.   If I isolate one of the PHY's as part of the PN_socHwinit function that is called early in main() would that be the best place?       Other than the call to PH_configurePHYLed's in TaskPruss,   I am having a hard time finding if there is other PHY initialization and hence if that would be the appropriate place to isolate one of the PHY's.

    Regards,

    Mark  

  • Hi Mark, just to close the debugger issue. It is related to enabling DMTimer4 before loading the application. For your information DMTimer4 is configured inside am335x_app_arm.cfg .
    In the case of using JTAG for loading the application, enabling DMTimer4 has to be done inside the GEL file. More details here: processors.wiki.ti.com/.../PRU_ICSS_Profinet

    For your reference, I tested using below GEL changes (highlighted) :

    C:\TI\ccsv7\ccs_base\emulation\boards\ice_am3359\gel\TMDXICE3359.gel

    //****************************************************
    //PRCM module definitions
    //****************************************************
    #define CM_PER_TIMER4_CLKCTRL (PRCM_BASE_ADDR + 0x88)
    #define PRCM_MODULEMODE_ENABLE (2U)

    hotmenu AM3359_ICE_Initialization()
    {
    GEL_TextOut("**** AM3359_ICE Initialization is in progress .......... \n","Output",1,1,1);
    ARM_OPP100_Config();
    //DDR2_EMIF_Config();
    DDR3_EMIF_Config();

    GEL_TextOut("Turning on EDMA... \n");
    EdmaPrcm();
    GEL_TextOut("EDMA is turned on... \n");
      
    WR_MEM_32(CM_PER_TIMER4_CLKCTRL, PRCM_MODULEMODE_ENABLE);
    GEL_TextOut("DMTIMER4 Enabled \n","Output",1,1,1);

    GEL_TextOut("**** AM3359_ICE Initialization is Done ****************** \n\n\n","Output",1,1,1);
    }

    Hope this helps.
    Paula

  • Mark,

    >> If I isolate one of the PHY's as part of the PN_socHwinit function that is called early in main() would that be the best place?
    Yes, PN_socHwinit() resets/initializes PHYs using default bootstrap configuration and you can isolate one of the PHY in the function.

    The other PHY related config is in the application layer UserApplyConf()-->UserSysEthSetPortMautype() -->PN_SetPhyConfig() which is port # based,

    Regards,
    Garrett