FEZ Cerberus Porting broken after changeset 16472 (July 13th)?

We get 2 following errors, the first probably concerning different GPIO_Typedef struct definitions used in different places of porting:

“c:\MicroFrameworkPK_v4_2\DeviceCode\Targets\Native\STM32\DeviceCode\STM32_GPIO\STM32_GPIO_functions.cpp”, line 66: Error: #20: identifier “AFIO_BASE” is undefined
UINT32 port = (AFIO->EXTICR[num >> 2] >> ((num & 0x3) << 2)) & 0xF;
^
“c:\MicroFrameworkPK_v4_2\DeviceCode\Targets\Native\STM32\DeviceCode\STM32_GPIO\STM32_GPIO_functions.cpp”, line 153: Error: #20: identifier “AFIO_BASE” is undefined
if ((AFIO->EXTICR[idx] & mask) != config) {
^
“c:\MicroFrameworkPK_v4_2\DeviceCode\Targets\Native\STM32\DeviceCode\STM32_GPIO\STM32_GPIO_functions.cpp”, line 187: Error: #20: identifier “AFIO_BASE” is undefined
} else if ((AFIO->EXTICR[idx] & mask) == config) {
^
“c:\MicroFrameworkPK_v4_2\DeviceCode\Targets\Native\STM32\DeviceCode\STM32_GPIO\STM32_GPIO_functions.cpp”, line 205: Error: #135: class “GPIO_TypeDef” has no member "CRH"
port->CRH = port->CRH & ~mask | config;
^
“c:\MicroFrameworkPK_v4_2\DeviceCode\Targets\Native\STM32\DeviceCode\STM32_GPIO\STM32_GPIO_functions.cpp”, line 205: Error: #135: class “GPIO_TypeDef” has no member "CRH"
port->CRH = port->CRH & ~mask | config;
^
“c:\MicroFrameworkPK_v4_2\DeviceCode\Targets\Native\STM32\DeviceCode\STM32_GPIO\STM32_GPIO_functions.cpp”, line 207: Error: #135: class “GPIO_TypeDef” has no member "CRL"
port->CRL = port->CRL & ~mask | config;
^
“c:\MicroFrameworkPK_v4_2\DeviceCode\Targets\Native\STM32\DeviceCode\STM32_GPIO\STM32_GPIO_functions.cpp”, line 207: Error: #135: class “GPIO_TypeDef” has no member "CRL"
port->CRL = port->CRL & ~mask | config;

…and the second maybe caused by similar issue for FLASH_TypeDef struct definition:

“c:\MicroFrameworkPK_v4_2\DeviceCode\Targets\Native\STM32\DeviceCode\STM32_Flash\STM32_Flash_driver.cpp”, line 258: Error: #135: class “FLASH_TypeDef” has no member "AR"
FLASH->AR = Sector;

Any suggestions?

Did you try to search where AFIO_BASE is defined?

Of course.

It should be definied in C:\MicroFrameworkPK_v4_2\DeviceCode\Targets\Native\STM32\DeviceCode\stm32f10x.h, but it was commented out (together with a different GPIO_TypeDef structure definition, inside a #if 0 / #endif block) by Steven (GHI):

Line 1419:
//#define AFIO_BASE (APB2PERIPH_BASE + 0x0000) N/A on STM32F40x

Line 999:
#if 0
/**

  • @ brief General Purpose I/O
    */

typedef struct
{
__IO uint32_t CRL;
__IO uint32_t CRH;
__IO uint32_t IDR;
__IO uint32_t ODR;
__IO uint32_t BSRR;
__IO uint32_t BRR;
__IO uint32_t LCKR;
} GPIO_TypeDef;
#endif

Looks like not everything is checked in. GHI?

We will look into why it is broken. Incidentally, we need to update the latest code Wednesday morning anyway.

Hi Innovactive and Architect,

Some how some unexpected files were included with one of the commits that did not belong. They were primarily the old F1 port that were in the STM32 folder before the majority of those files were moved to the STM32F4 folder. I think when you connected to the repository the compiler was linking to those older files instead of the latest F4 port. Please reconnect to the repository and test the fixes that were made.

Hi Aron.

Now it complains about processor_selector.h missing, with 102 errors like this:

c:\MicroFrameworkPK_v4_2\Solutions\FEZ_Cerberus\platform_selector.h", line 123: Error: #5: cannot open source input file “processor_selector.h”: No such file or directory

Should device code be picked from STM32 or STM32F4 directory? STM32F4 does contain such file, STM32 not.

Any suggestions?

Actually I realized we have both FEZ_Cerberus and FEZCerberus solutions…the latter is the right one, isn’t it?

Now it builds fine, thanks!

Just a question: are common directories about STM32 (STM32F2, STM32F4 and STM32) platform mergeable with oberon ones?

We’d like to get latest versions of codeplex source control systems of two projects over same SPOL_CLIENT dir…

As you may have already determined, FEZCerberus is based on Oberon’s F4 port while FEZ_Cerberus is a modified F1 port to work with the F4 chip.

As for the merging with Oberon’s port, you can merge them to get the most up to date code but you would have to make a few modifications that we needed to do to make it work for Cerberus and its cousins, mainly with the UART ports. What you could do is download Oberon’s port and do a file compare to see which base files have been modified.

Actually (I have just checked) at this time Oberon hasn’t FEZCerberus solution anymore under their codeplex project.

On their source control they have only Discovery4, STM32Stamp, STM3220G and STM3240G solutions, so it seems they won’t explicitly target FEZCerberus anymore: am I wrong? Obviously, shared “devicecode\native…” files will influence GHI solution too, so I think we should do some test…

No you are not wrong. Oberon is not directly targeting the Cerberus anymore and has left that to us as we know Cerberus’s hardware more intimately. However, to utilize Oberon’s ports as they set up in their solutions, you would not be able to use the GHI modified files from our custom port. As I said, the changes are minor and perhaps you could add an #ifdef to isolate the differences.

Well, at least merging such 2 branches (the GHI one and over that the Oberon one) does not break “buildability”, since it builds well.

We’re going to run some tests to check whether it breaks some runtime behavior (such as uart related behavior you mentioned) and let you know.

Thanks, Aron.

You’re welcome Innovactive.

To get an idea on what runtime behavior may break, just do a comparison of Oberon’s vs GHI to fully see the differences that are implemented. There are not a lot but they are scattered here and there.