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.

VC5502 McBSP2 Selection via GPIO7

Has anyone ever had any issue getting McBSP2 selected (i.e. XBSR.GPIO7 set) by pulling the GPIO7 pin high during release of reset on a 5502?

I tried this out on the EVM and it appears to work for me, but I have been working with an engineer with a custom board where if GPIO7 is pulled high the McBSP2 never seems to be selected properly (kind of like this old DSPRelated thread), XBSR.GPIO7 is never set. This being said, there are a couple of specific questions:

1. Is it possible that package could impact the selection of McBSP2? The EVM I tested with uses a BGA package yet the custom board this is failing on uses a PGF package.

2. Could any other combination of boot strap settings prevent McBSP2 from activating? I could see setting it to UART boot mode with GPIO7 high conflicting, but perhaps there is some other unknown bad interaction, maybe GPIO6 being high?

  • Hi Bernie,

    This is not a known issue. I would like to see if XBSR.GPIO7 will hold a 1 if written to after reset.

    I would also like to see if GPIO6 works as described:
    GPIO6 = 1: XBSR.GPIO6 reads 1 & The Parallel Port Mux is configured to support the HPI in 16-bit (non-multiplexed) mode and PGPIO.
    GPIO6 = 0:
    XBSR.GPIO6 reads 0 & The Parallel Port Mux is configured to support the 32-bit EMIF

    We have only the BGA package on the 5502 EVM, so I cannot reproduce the problem. But looking at the PGF pin-out, I wouldn't rule out the possibility that GPIO6 and GPIO7 pins are swapped. Please have the customer test  GPIO6 and GPIO7.

    Thanks,
    Mark

  • It looks like having restarted everything today that it appears to be working properly, so the current theory is that this is a general board stability/layout problem, and not something specific to the VC5502. At this point if any new findings are discovered we can bump this thread, though for now the issue can be considered closed, thanks for the feedback.