• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 101 subscribers
  • Views 1231 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.

TMS320C6748: McBSP0 hang resume

Tony Tang
Mastermind 29592 points
Part Number: TMS320C6748


In customer system, sometimes McBSP0 transmitter hang: can't send out data, although XRDY is set, write data to DXR, the DX data line still remain 0. But the device other function seems still in order, for example UART still output data.

So hope to reset McBSP0 to resume it to default state to initialize it again. but system will hang after disable it from PSC. For debug convenience, we make it in gel file.

Before hang, with the same gel file, we can disable/enable McBSP0 whatever times without any problem.

We

use OMAPL1x_debug.gel read out device status before hang and after hang, the difference at ROM status Code, before hang is 0xCF, after hang is 0xFF. I attached the debug gel outputs.

Can it tell us what is status changed from this Code?

Why can't disable McBSP0 from PSC? what is the status? and what is the possible reason result in McBSP into this status?Gel_Debug.zip

  • 0
    TI__Guru**** 161600 points
    Hi Tony,

    We're looking into this.

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    TI__Mastermind 29592 points
    Thanks Yordan, we are looking forward feedback. This is a very important customer's project.
  • 0 in reply to Tony Tang
    TI__Guru** 116770 points
    Tony,

    Please reconfirm that they are implementing the entire sequence listed 26.2.15. It is important that there are no outstanding , inflight , incoming transactions on the McBSP logic (and EDMA) , if any portion of the state machines are active, the clock stop request will not be acknowledged by the module which could result in the hung state.

    You indicated "Before hang, with the same gel file, we can disable/enable McBSP0 whatever times without any problem." what does this mean. Does it mean that the hang occurs only sometimes but other times the module can be enabled and disabled correctly using LPSC? Can you make sure that you close Memory browser and Register view before you run the GEL function. If emulator is trying to read the memory/registers when the module goes through this reset then we have seen such errors.

    If you are enabling and disabling MCBSP, what does that have to do with ROM status code. The ROM status is a value that is valid only when BootROM has completed execution as it is a location in DSP internal memory that is used by ROM to store status when it is executing. After the application has been loaded, this region can be re-used by the application for other purpose so I am not sure the value is reflecting anything valid to the bootROM.

    Regards,
    Rahul

    PS: Also check discussion between Mukul and Kawada-san.
    e2e.ti.com/.../1726371
  • 0 in reply to Rahul Prabhu
    TI__Mastermind 29592 points

    Rahul Prabhu said:
    You indicated "Before hang, with the same gel file, we can disable/enable McBSP0 whatever times without any problem." what does this mean. Does it mean that the hang occurs only sometimes but other times the module can be enabled and disabled correctly using LPSC? Can you make sure that you close Memory browser and Register view before you run the GEL function. If emulator is trying to read the memory/registers when the module goes through this reset then we have seen such errors.

    I mean before McBSP get stuck, we can enable/disable correctly using PSC arbitrarily. no matter close memory browser and register or not. 

    Rahul Prabhu said:
    If you are enabling and disabling MCBSP, what does that have to do with ROM status code. The ROM status is a value that is valid only when BootROM has completed execution as it is a location in DSP internal memory that is used by ROM to store status when it is executing. After the application has been loaded, this region can be re-used by the application for other purpose so I am not sure the value is reflecting anything valid to the bootROM.

    Just use debug gel to check device status, only find this difference, not intend to read ROM status.

    There is no conclusion of Kawada-San post, not sure whether his problem solved or not. Anyway we will follow 26.2.15 to try again, will let you know the result.

  • 0 in reply to Tony Tang
    TI__Guru* 84555 points

    Tony

    Still catching up on this thread and you are right the Kawada-san thread does not show any conclusion. 

    >>I mean before McBSP get stuck, we can enable/disable correctly using PSC arbitrarily. no matter close memory browser and register or not. 

    Can you clarify this statement further? Is it that if McBSP is stuck , PSC is not able to always reset or recover McBSP from this state? If so it is expected 

    It may still be worthwhile to see why the McBSP is in the bad state in the first place.

    It the McBSP state machine is hanging then I do not expect the PSC to gracefully allow clock disable or local reset etc unless you use the FORCE bit in the MDCTL register (bit 31). 

    Have you tried that too?

    Regards

    Mukul 

  • 0 in reply to Mukul Bhatnagar
    TI__Mastermind 29592 points

    Mukul,

    Mukul Bhatnagar said:
    s it that if McBSP is stuck , PSC is not able to always reset or recover McBSP from this state? If so it is expected 

    Yes, when McBSP is stuck, not able to reset or recover McBSP always.

    Mukul Bhatnagar said:
    It may still be worthwhile to see why the McBSP is in the bad state in the first place.

    Not sure why enter stuck status, due to can't send out data through McBSP0, XRDY always remain set, write data to DXR, data line always remain 0, FSX and CLKX still active (it is master mode).

    Since not sure the cause, customer tried many method to reproduce this phenomenon, finally found when PRU and DSP access McBSP at the same time, it can trigger McBSP stuck. But customer checked software, there is no such operation in code.

    Today customer tried FORCE to disable/enable McBSP0, still can't recover McBSP0. after force disable, McBSP registers value change to 0, but enable McBSP0 from PSC again, McBSP0 registers recover to previous value, so the McBSP0 is not reset actually.

    Is there further procedure to reset McBSP0 after FORCE?

  • 0 in reply to Tony Tang
    TI__Guru* 84555 points

    Hi Tony

    Today customer tried FORCE to disable/enable McBSP0, still can't recover McBSP0. after force disable, McBSP registers value change to 0, but enable McBSP0 from PSC again, McBSP0 registers recover to previous value, so the McBSP0 is not reset actually.

    Can you share the sequence on what they tried?

    If they tried the state to disable (MDCTLn.NEXT = 2h) that may not be sufficient , can they try syncreset or swrstdisable, and if that does not work try LRST (MDCTL bit 8) 

    They only have to have the force bit enabled when they try to reset the McBSP via PSC, they do not need to program the bit when they are reenabling the clocks (NEXT=enable)

    I am assuming RRDY is no issue? There was a recent post on C5517 McBSP hang (McBSP lineage is the same for both the processors)

    e2e.ti.com/.../2445936

    Regards

    Mukul 

  • 0 in reply to Mukul Bhatnagar
    TI__Mastermind 30170 points
    Tony,

    Can you confirm the customer code always polls for XRDY to be set before writing into DXR registers? Either by polling XRDY or waiting on interrupt / DMA event.

    Is there any difference in the DX data line when they write all F's vs all 0's into the DXR register? Or does it always stay low (0)?

    Are any other error flags set in the McBSP registers? Like XSYNCERR or XEMPTY?
    What are the states of Emulation mode bits FREE and SOFT?

    Regards,
    Mark
  • 0 in reply to Mukul Bhatnagar
    TI__Mastermind 29592 points

    Mukul,

    Mukul Bhatnagar said:
    If they tried the state to disable (MDCTLn.NEXT = 2h) that may not be sufficient , can they try syncreset or swrstdisable, and if that does not work try LRST (MDCTL bit 8) 

    Force+Disable doesn't work. 

    Force+SwRstDisable Works.

    Thank you. this issue closed.

  • 0 in reply to Mark M
    TI__Guru* 84555 points
    Mark
    Thanks for chiming in on the thread.

    Tony
    Good to know swrstdisable works, remember disable is only enabling/disabling clocks , syncreset "resets" the module, swrstdisable resets and disables the module. In most scenarios we do not expect customers to use syncreset or swrstdisable, but it will enable them to "locally" reset the peripheral.


    If we ever want to reengage in trying to understand the hang condition , please do open a new thread and help clarify the questions Mark raised here.

    TI recommendation will be to identify the source of the hang, Force bit is a brute force way of doing a localized reset, the docs encourage users not to rely on it, but if that is sufficient for what your customer is trying to accomplish right now, I leave that judgement to them.

    Regards
    Mukul