Post Go back to editing

SC589-EZKIT with EI3 Extender as a SPI device

Category: Software
Software Version: CCES 2.10.1.0

I'm attempting to set up a SC589-EZKIT as a SPI device using a EI3 extender connected to P1B & P1C.

For some reason I cannot see the GPIO any pins on the EI3 extender changing from the ARM or SHARC0 cores, but observe proper SPI signaling with a digital scope on the extender.

Is there something that must be done to enable/configure the extender card?



Clarification of observations
[edited by: rireland at 5:18 PM (GMT -4) on 26 Jul 2022]
  • It appears there's a Power LED on the EI3 that should be lit when "powered correctly" but it stays off.  So either the board is bad, the LED is bad, or there's some configuration option that is undocumented.

  • Hi Rireland,

    Regarding, Is there something that must be done to enable/configure the extender card?
    No, after connecting extender to EZkit, you can probe all the signal present in extender card.

    Each port pin can be configured individually to serve as a GPIO pin or as a peripheral-specific pin. By default, Port pins are in GPIO mode.


    The function enable register specifies whether the pin is used as a GPIO pin or allocated for use by a specific peripheral, but it does not specify what the peripheral function is. Each bit in the 16-bit PORT_FER register corresponds to an individual port pin. For example, if bit 1 (PA1) of the PORTA_FER register is cleared, the PA_01 pin is configured as a GPIO. When set, one of the available peripheral functions becomes active on the PA_01 pin instead.

    Please let us know, which port pin do you have probed and what output you got?

    Regards,
    Anand Selvaraj.

  • After reviewing the schematic more closely, the LED isn't active because the SC589 EZKit doesn't connect the VIN pin to anything.  Connecting it to PS_IN results in the LED activating.

    Would be nice to have that called out specifically in the SC589 EZKit user manual.

  • However, using the polled GPIO example to attempt to read GPIO pins isn't successful for me somehow.  I can see the on-board button presses, but not much else.

  • I'm probing all the ports looking for any change.  It shows a change when the on-board switch is pressed, but not when driving from rPI SPI port.

    Code based on Cortex GPIO polling example:

    uint8_t  gpio_mem[4096];
    uint32_t gpio_max_callbacks = 0;
    
    
    /* callback for receiving GPIO input events */
    void gpioCallback(ADI_GPIO_PIN_INTERRUPT ePinInt, uint32_t PinIntData,  void *pCBParam)
    {
    	if (ePinInt == ADI_GPIO_PIN_INTERRUPT_4)
    	{
    		if (PinIntData & ADI_GPIO_PIN_1)
    		{
                /* got a push button event */
                printf("Push Button 2 pressed\n");
    		}
    		else
    		{
    			printf("Callback pin = %lu, data = %lu, param = %p\n", ePinInt, PinIntData, pCBParam);
    		}
    
    	}
    	else
    	{
    		printf("Callback pin = %lu, data = %lu, param = %p\n", ePinInt, PinIntData, pCBParam);
    	}
    }
    
    
    int main()
    {
    	/**
    	 * Initialize managed drivers and/or services that have been added to 
    	 * the project.
    	 * @return zero on success 
    	 */
    	adi_initComponents();
    
    	puts("Starting...\n");
    	ADI_GPIO_RESULT result = adi_gpio_Init(gpio_mem, sizeof(gpio_mem), &gpio_max_callbacks);
    
    	printf("GPIO Service Initialized: %d : %lu\n", result, gpio_max_callbacks);
    
    
    	/* set the GPIO direction */
    	/* On the SC589 EZ-Board Push Button 2 is connected to Port F - Pin 1 */
    	//result = adi_gpio_SetDirection(ADI_GPIO_PORT_F, ADI_GPIO_PIN_1, ADI_GPIO_DIRECTION_INPUT);
    	for (ADI_GPIO_PORT port= ADI_GPIO_PORT_A; port < ADI_GPIO_PORT_A + NUM_GPIO_PORTS; port++)
    	{
    		for (uint32_t pin = 0; pin < 32; pin++)
    		{
    			result = adi_gpio_SetDirection(port, 1 << pin, ADI_GPIO_DIRECTION_INPUT);
    
    			if ( result )
    			{
    				printf("Failed to set port %u, pin %u, direction: res = %u\n", port, pin, result);
    			}
    		}
    	}
    
    	/* set edge sense mode (PORT F is connected to Pin Interrupt 4) */
    	result = adi_gpio_SetPinIntEdgeSense(ADI_GPIO_PIN_INTERRUPT_4, ADI_GPIO_PIN_1, ADI_GPIO_SENSE_RISING_EDGE);
    
    	/* register pinint 4 callback */
    	result = adi_gpio_RegisterCallback(ADI_GPIO_PIN_INTERRUPT_4, ADI_GPIO_PIN_1, gpioCallback, (void*)0);
    
    	/* enable the pin interrupt mask */
    	result = adi_gpio_EnablePinInterruptMask(ADI_GPIO_PIN_INTERRUPT_4, ADI_GPIO_PIN_1, true);
    
    	/* wait for the GPIO input event */
    
    	while(1)
    	{
    		uint32_t data[NUM_GPIO_PORTS];
    		uint32_t data_in[NUM_GPIO_PORTS];
    
    		for (ADI_GPIO_PORT port= ADI_GPIO_PORT_A; port < ADI_GPIO_PORT_A + NUM_GPIO_PORTS; port++)
    		{
    	        adi_gpio_GetData(ADI_GPIO_PORT_F, &data_in[port]);
    	        if (data_in[port] != data[port])
    	        {
    	        	printf("Port %u changed %08lX\n", port, data_in[port]);
    	        	data[port] = data_in[port];
    	        }
    		}
    	}
    	
    	/**
    	 * The default startup code does not include any functionality to allow
    	 * core 0 to enable core 1 and core 2. A convenient way to enable
    	 * core 1 and core 2 is to use the adi_core_enable function. 
    	 */
    	adi_core_enable(ADI_CORE_SHARC0);
    	adi_core_enable(ADI_CORE_SHARC1);
    
    	/* Begin adding your custom code here */
    
    	return 0;
    }
    

    Output in the CCES debug console:

    Starting...
    
    GPIO Service Initialized: 0 : 256
    Port 0 changed 000097FC
    Port 1 changed 000097FC
    Port 2 changed 000097FC
    Port 3 changed 000097FC
    Port 4 changed 000097FC
    Port 5 changed 000097FC
    Port 6 changed 000097FC
    Push Button 2 pressed
    Port 6 changed 000097FE
    Port 6 changed 000097FC
    Push Button 2 pressed
    

    And all that time I had an rPI running a slow (5kHz) SPI transaction to SPI1 (PE_11 through PE_15) just see if the pins move. Perhaps my voltages are too low/high, the rPI is driving 3.3V?


  • I've found my bug.  I was only testing port F for changes.  Sorry for the distraction.

  • Hi Rireland,

    Thanks for the update and glad to know that the issue is resolved. Please let us know if you need further assistance on this.

    Regards,
    Anand Selvaraj.