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.

Transfer of parallel data from AM1808 with WAIT activated.

Other Parts Discussed in Thread: AM1808, OMAP-L138

Hi All,

Have a great day. 

Subject: Transfer parallel data from AM1808 to customer board with WAIT activated.

Board Setup: AM1808 board  interfaced with customer board (receiver chip).

The setup is AM1808 will send 8 bit parallel data on channel-B (transmit mode) along with CLOCK (output) and ENABLE (output) which act as DATA-VALID.  The receiver chip will capture data when ENABLE=1.  This setup works fine as expected. i.e. The data transfer from AM1808 to receiver chip is successful.

Now the receiver chip want's to halt the transfer (if its internal FIFO goes to almost full) so we have configured WAIT (input to AM1808) signal with ACTIVE high polarity.  Here are the more register setting for uPP interface.

UPICR.TRISB=0 

UPICR.WAITB=1 (WAIT is enabled for channel-B)

UPICR.WAITPOLB=0 (WAIT is configured as active HIGH)

UPCTL.MODE[1:0] [Field 1to 0] = 1h (All transmit mode)

The issue we noticed is AM1808 is continue sending DATA even though WAIT is set to logical HIGH.  The expected behavior is AM1808 should stop sending data. Also observed that WAIT signal is forcefully driven to active LOW by AM1808 even though we configured as INPUT mode. 

Please help us to solve above issue, I am ready to share more details if required. Thanks a lot.

Best Regards,

Magesh S

 

  • Hi,

    Team is working on and we will let you know the update as soon as possible.

    Thanks & regards,

    Sivaraj K

  • Hello Magesh,

    In transmit mode, the WAIT signal must be asserted when you driven it from receiver. It cannot change its state on its own unless you are pulling it to the other state. 

    Though your register settings are right, Could you ensure the following.

    1. Internal PU/PD resistor selection on uPP_CHB_WAIT pin ? The selection should be PU (default).

    2. Is there any external pull down resistor on uPP_CHB_WAIT signal ? please share the schematics if possible.

    3. Try changing the UPICR.WAITPOLB to 1 and drive the wait signal as active low from the receiver. While doing this the internal PU/PD selection should be in PD.

     

    Regards,

    Senthil

  • >> Thanks Senthil for your prompt reply.  

    1. Internal PU/PD resistor selection on uPP_CHB_WAIT pin ? The selection should be PU (default).

    >> Currently we had disabled the PUPD_ENA by setting to 0xBFFF_FFFF, hence PUPD_SEL is not applicable. i.e. no PU/PD applied on uPP_CHB_WAIT. Now will reconfigure PUPD_ENA to 0xFFFF_FFFF as well set PUPD_SEL to 1 (default) and try it out.  Will keep you posted on our progress.

    2. Is there any external pull down resistor on uPP_CHB_WAIT signal ? please share the schematics if possible.

    >> There is no PU/PD resistor on board.

    Best Regards,

    Magesh S

  • Hello Magesh,

    If you still see the issue on wait signal after your experiment, you could debug on the receiver side.

    You can also try to isolate the WAIT signal from AM1808 and check the status by asserting the signal from receiver.

    Since the WAIT signal is input for uPP channel B, the AM1808 doesn't have any control over this signal. 

    Regards,
    Senthil

  • Sure Senthil. We have already isolated receiver board and configured WAITB as PU and setting WAITB polarity as active high.

    Now its expected that AM1808 should not start the transmission since WAITB is active HIGH through PU. But we do see AM1808 is continuing transmission. Will debug bit more and let you know further status and queries. 

    Thanks for your followup.

    Best Regards,

    Magesh S

  • Senthil,

    Subject:  Failed to read logical HIGH on GP8P12 field (Pin: G4) which configured as GPIO INPUT signal.

    Today we had configured AM1808 in "GPIO mode" and tested UPP_CHB_WAIT (pin-G3). When we configured as direction as OUTPUT, then we are able to drive both logical HIGH and LOW (observed on LA), this is expected.

    But when we configured as INPUT mode and drive logical HIGH  and dump value (gpio140/value) it is always shows logical LOW. 

    Similarly we had tested other pins in INPUT mode (example: UPP_CHB_ENABLE, UPP_CHB_CLOCK) and these pins are working fine (able to read logical HIGH and logical LOW based on input stimuli).

    PINMUX18 = 0x0044_4400

    Here are the configuration settings used. Please help us to debug. We are based on Bangalore and we really appreciate if we get direct AE support in-house. Thanks.

    Best Regards,

    Magesh S

  • Hello Magesh,

    I will check this issue at my end and update you.

    Meanwhile, could you please share your schematics to review your uPP interface design.

    Regards,

    Senthil

  • Sure Senthil. Here I have attached the schematics.

    1016572B_AM1808_OMAP-L138_Baseboard_Schematic.pdf - AM1808 board schematic.
    UPP_Connector_For_Saankhya.pdf - AM1808 to Saankhya labs connector board schematic.

    Really appreciate your quick response on this.

    Best Regards,

    Magesh S3107.UPP_Connector_For_Saankhya.pdf3771.UPP_Connector_For_Saankhya.pdf3617.1016572B_AM1808_OMAP-L138_Baseboard_Schematic.pdf

  • Hello Magesh,

    The GPIO number and PINMUX18 register value that you mentioned is not correct for GPIO configuration of G3 pin.

    The GPIO number is 141 for G3 pin and PINMUX18 = 0x00844 4400.

    Please try this settings in your code and check.

    Moreover, i checked the G3 pin behavior as GPIO input in my end. It is working fine as expected.

    int main(void)
    {
    
    /* GPIO Loopback Testing */
    
        /* The Local PSC number for GPIO is 3. GPIO belongs to PSC1 module.*/
        PSCModuleControl(SOC_PSC_1_REGS, HW_PSC_GPIO, PSC_POWERDOMAIN_ALWAYS_ON,
    		     PSC_MDCTL_NEXT_ENABLE);
    
        
        /* Pin Multiplexing of pin 10 of GPIO Bank 8.*/
        GPIOBank8Pin10PinMuxSetup();
    
        /* Pin Multiplexing of pin 12 of GPIO Bank 8.*/
        GPIOBank8Pin12PinMuxSetup();
    
        /* Sets the pin 109 (GP6[12]) as input.*/
        GPIODirModeSet(SOC_GPIO_0_REGS, 109, GPIO_DIR_OUTPUT);
    
        /* Sets the pin 141 (GP8[10]) as input.*/
        GPIODirModeSet(SOC_GPIO_0_REGS, 139, GPIO_DIR_OUTPUT);
    
        /* Sets the pin 141 (GP8[12]) as input.*/
        GPIODirModeSet(SOC_GPIO_0_REGS, 141, GPIO_DIR_INPUT);
    
    while(1)
    {
    
        GPIOPinRead(SOC_GPIO_0_REGS, 141);
    
        GPIOPinWrite(SOC_GPIO_0_REGS, 139, GPIO_PIN_LOW);
    
        GPIOPinRead(SOC_GPIO_0_REGS, 141);
    
        GPIOPinWrite(SOC_GPIO_0_REGS, 139, GPIO_PIN_HIGH);
    
        GPIOPinRead(SOC_GPIO_0_REGS, 141);
    
    }

    Regards,
    Senthil

  • Thanks a lot Senthil. We had sorted out the issue, here are the details.

    - We had tried on another AM1808 board there pin: G3 (UPP_CHB_WAIT) is working as expected  for both GPIO mode as well uPP mode.

    - I guess that on previous board the pin G3 BIDI/input buffer might have burnt/damaged. During our experimentation we accidentally driven strong logical HIGH (5 Volt).

    Thanks again for your sincere followup and I would like to close the case. Please let me know if you need any further information. 

    Best Regards,

    Magesh S

  • Hello Magesh,

    Thanks for your update.

    As you said, the IO buffer might have been damaged due to 5V logic. The IO level of G3 pin is 3.3V and it is not tolerant to 5V.

    Could you please help to close this thread by clicking "Verify Answer" button.

    Regards,

    Senthil

  • Hi Magesh,

    Thanks for your update.

    - We had tried on another AM1808 board there pin: G3 (UPP_CHB_WAIT) is working as expected  for both GPIO mode as well uPP mode.

    - I guess that on previous board the pin G3 BIDI/input buffer might have burnt/damaged. During our experimentation we accidentally driven strong logical HIGH (5 Volt).

    Have you changed any code related to uPP configuration or any other changes or as you said any hw problem?