Hi,in our design we use EMAC with different GPIO layout than in ControlSuite v140 lwIp example. EthernetPinsSetup() was modified according to our design, but the lwIp example doesn't work. The CPU is Concerto F28M35H52C.Q1. In lwIp example and in this (http://e2e.ti.com/support/microcontrollers/tms320c2000_32-bit_real-time_mcus/f/171/p/164864/600861.aspx) different pins layout, the GPIO_O_APSEL register is not fully programmed in conjunction with PCON register, but the "spruh22.pdf" reference manual told that it should be:"The proper bits in the Alternate Peripheral Select (GPIOAPSEL) register must be set to access these muxing options", "When these bits are set, values of 0x0 - 0xF are valid values in the GPIOPCTL PMCx bit fields."
Lwip example goes in contradiction with it. E.g.:
// MII_TXD3 GPIODirModeSet(GPIO_PORTC_BASE, GPIO_PIN_4, GPIO_DIR_MODE_HW); GPIOPadConfigSet(GPIO_PORTC_BASE, GPIO_PIN_4, GPIO_PIN_TYPE_STD); HWREG(GPIO_PORTC_BASE + GPIO_O_PCTL) &= 0xFFF0FFFF; HWREG(GPIO_PORTC_BASE + GPIO_O_PCTL) |= 0x00030000; - APSEL not programmed for MII_TXD3
// MII_TXCK , MII_TXEN , MII_TXD0 , MII_TXD1 , MII_TXD2 , MII_RXD0 GPIODirModeSet(GPIO_PORTH_BASE, GPIO_PIN_7|GPIO_PIN_6|GPIO_PIN_5|GPIO_PIN_4| GPIO_PIN_3| GPIO_PIN_1, GPIO_DIR_MODE_HW); GPIOPadConfigSet( GPIO_PORTH_BASE, GPIO_PIN_7|GPIO_PIN_6|GPIO_PIN_5|GPIO_PIN_4| GPIO_PIN_3| GPIO_PIN_1, GPIO_PIN_TYPE_STD); HWREG(GPIO_PORTH_BASE + GPIO_O_APSEL)|= 0x000000C2; HWREG(GPIO_PORTH_BASE + GPIO_O_PCTL) &= 0x00000F0F; HWREG(GPIO_PORTH_BASE + GPIO_O_PCTL) |= 0xCC9990C0;- APSEL not programmed for MII_TXDn pins
and so on.
For our layout we set an APSEL bits in all places where PCTL's tetrade isn't 0, but the result in functionality is negative.In which cases the APSEL bit should be set or not in conjunction with PCTL tetrade?Q2. Do you test the alternate function of each available GPIO? When we used the MDIO as alt. function of the PF4_GPIO36's pin, this pin is always set to 1. But when it used as PE6_GPIO30's alt. function (as in example), it transmits some interface data.
This initialization we used to set the MDIO on the PF4_GPIO36 pin, but got a fail.
// MDI0 RXD3 GPIODirModeSet(GPIO_PORTF_BASE, GPIO_PIN_4|GPIO_PIN_5, GPIO_DIR_MODE_HW); GPIOPadConfigSet(GPIO_PORTF_BASE, GPIO_PIN_4|GPIO_PIN_5, GPIO_PIN_TYPE_STD); HWREG(GPIO_PORTF_BASE + GPIO_O_APSEL)|= 0x00000030; HWREG(GPIO_PORTF_BASE + GPIO_O_PCTL) &= 0xFF00FFFF; HWREG(GPIO_PORTF_BASE + GPIO_O_PCTL) |= 0x00330000;
Hi,
(1)The GPIOAPSEL register bit need to be set only when the respective pins are used in alternate mode. The example code you are referring is using all the pins in primary mode hence there is no write to GPIOAPSEL register (default value '0' which selects the primary mode).
(2) MDIO is available on PF4_GPIO36 pin in primary mode not in alternate mode hence one need not to set the GPIOAPSEL register bit. If GPIOAPSEL register bit is set then this'll not work as MDIO. In case of PE6_GPIO30 pin, MDIO is available on this pin in alternate mode hence one need to set the GPIOAPSEL register bit which is why it's working.
Hope I was able to answer your questions. Let us know if you have any further query on this.
Regards,
Vivek Singh
If my reply answers your question please click on the green button "Verify Answer".
Ok, till the moment you answer me, I already tried to put "1" in APSEL for functions from table 4.2 of "spruf22.pdf" and "0" for others and got it workable. But the Manual was really caused the misunderstanding of the APSEL meaning. It has tables 4.1 and 4.2 that are both named "GPIO Pins and Alternate [Mode] Functions". Not a word "primary" is used in tables and GPIOAPSEL description!
"GPIO Alternate Peripheral Select (GPIOAPSEL) Register, offset 0x530The GPIOAPSEL register is used to access the M3 GPIO alternate peripheral muxing options. Whenthese bits are set, values of 0x0 - 0xF are valid values in the GPIOPCTL PMCx bit fields. See Table 4-1for alternate muxing options."
Reading this, I thought that APSEL is just awesome AFSEL clone that just makes 0x0 - 0xF values available.
Best regards!
Thanks for bringing this up to our notice. We'll see if providing some further notes in the manual can avoid such confusion in future.