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

Hang problem when switching UART debug port from UART3 to UART2

Luan Le
Expert 2280 points
Other Parts Discussed in Thread: OMAP3530

Hello,

From Wiki page WinCE-TIBSP FAQ, it is possible to use UART1/2 for Serial debug message by changing the debugUartCfg structure inside SRC\BSP_COMMON\BSPCFG\bspcfg.c

In the debugUartCfg structure of the original EVM_OMAP3530 BSP, I changed the "dev" value from OMAP_DEVICE_UART3 to OMAP_DEVICE_UART2 and also added pad configuration for UART2 in XLDR code. 

 

During the XLDR/EBOOT/NK.BIN download, there were debug outputs coming from UART2.  However, the EVM hangs at "Launch Windows CE image by jumping to 0x8001XXXX..."

I also got the same result on my custom board.

Is is a known problem?  I appreciate any tips/advice you can give me.

Thanks,

Luan

  • 0
    TI__Mastermind 41665 points

    Luan Le said:
    During the XLDR/EBOOT/NK.BIN download, there were debug outputs coming from UART2.  However, the EVM hangs at "Launch Windows CE image by jumping to 0x8001XXXX..."

    When you say it hangs, do you mean that WinCE never finishes booting and you see nothing on the LCD, or just that the output on the UART2 stops happening? It sounds like what you are doing here is reasonable, so my initial thought would be that there is just some problem with the serial port configuration and not WinCE as a whole, though I am not intimately familiar with the BSP so I will have to leave it to the BSP folks to comment further.

  • 0 in reply to Bernie Thompson TI
    Expert 2280 points

    Hi Bernie,

    You are right.  WinCe never finishes booting, output from UART2 stops, and nothing is shown on the LCD.

    We are about to go to production testing of WinCE and our OMAP custom board, so it is very critical to us to have this problem fixed asap.

    I appreciate all the helps from the TI's team.

    Regards,

    Luan

  • 0 in reply to Luan Le
    TI__Expert 4155 points

    Luan,

    I am able to reproduce the issue, the problem is caused by debug serial clock is not enabled for UART1/UART2 in OAL. The OAL code use hard coded value for UART3.

    One way to solve the issue is to keep debugserial clock enabled in Eboot.

    Here are the changes you will need :

    1. Change debug port to UART1/UART2 in bspcfg.c

    2. Enable corresponding UART PAD configurations in XLDR.(PinMuxSetup() in platform.c)

    3. Enable corresponding UART PAD configuration in OAL (init.c)

        ConfigurePadArray(BSPGetDevicePadInfo(OMAP_DEVICE_UART2));

    4. enable debug serial clock before launch the Kernel.(OEMLaunch() in main.c)

        EnableDeviceClocks(BSPGetDebugUARTConfig()->dev, TRUE);

        JumpTo(OALVAtoPA((UCHAR*)launch));

    If debug serial is not used (Retail message is disabled from Eboot menu), then the clock for debug serial port will be disabled in Init.c.

    Thanks,

    Tao

     

     

  • 0 in reply to Tao Zhang
    TI__Expert 4155 points

    Luan,

    Instead of always enabling Debug serial port clock in Eboot, there is another way to fix the issue - Update function EnableDebugSerialClock() to support UART1/UART2.

    Code changes are updated in TIBSP FAQ:

    http://processors.wiki.ti.com/index.php/WinCE-TIBSP_FAQ#Q:_Is_it_possible_to_use_UART1.2F2_for_Serial_debug_message.3F

    Thanks,

    Tao

  • 0 in reply to Tao Zhang
    Expert 2280 points

    Hi Tao,

    Following your instructions, the hang problem is now fixed when using UART2 for debug serial.  However, from somewhere during the booting, RETAILMSG and OALMSG stop working.  For instance, the lines below are no longer output :

    SDHC: CPU revision 0x6
    Init Touch Controller with GPIO 162 and INT 290

    even though in sdhc.cpp,

    RETAILMSG(1, (L

    "SDHC: CPU revision 0x%x\r\n", m_dwCPURev));

     

    and in touchscreen.cpp,

    OALMSG(1, (L

    "Init Touch Controller with GPIO %d and INT %d\r\n", s_TouchDevice.nPenGPIO, s_TouchDevice.nPenIRQ));

    When UART3 is used, these two lines are output.

  • 0 in reply to Luan Le
    TI__Expert 4155 points

    Luan,

    Could you please check your catalog items view to see UART2 is enabled as a UART driver?

    If yes, when COM driver initialized, it is not used as debug port anymore.

    Thanks,

    Tao

  • 0 in reply to Tao Zhang
    Expert 2280 points

    Hi Tao,

    Thank you very much for the tip - yes, I have UART2 checked in my catalog.

    I unchecked it and the COM2 debug is working now.

    Thanks for your help,

    Luan

  • 0 in reply to Luan Le
    TI__Expert 4155 points

    Luan,

    I am glad the problem is solved.  I am not sure what solution you have used, I just want to remind you that I have added a cleaner way to solve the issue on the wiki FAQ page. We will use that approach in ARM_A8 BSP.

    Thanks,

    Tao

  • 0 in reply to Tao Zhang
    Expert 2280 points

    Hi Tao,

    I am using the (b) option in which startup.s is modified to pass the debug port to EnableDebugSerialClock().  I also thought it is cleaner way.

    Thanks,

    Luan