EFM32 PeripheralPins.c

[DBS06]

Description

Target: EFM32PG12B500F1024GL125

I tried to use a different USARTn for SPI (in EFM32PG12_STK3402 USART2 is used) and looked inside the "EFM32PG12 Family Data Sheet - Chapter 6.4 Alternate Functionality Overview" and for USART3 the Profile No.1 should work for me.

Therefore I tried to create an SPIF object like this:
PinNames.h:

#ifndef MBED_PINNAMES_H
#define MBED_PINNAMES_H

#include "CommonPinNames.h"

#ifdef __cplusplus
extern "C"
{
#endif

    typedef enum
    {
        EFM32_STANDARD_PIN_DEFINITIONS,

        USBTX= PA0,
        USBRX= PA1,
[...]
        SPI_MOSI = PD9,
        SPI_MISO = PD10,
        SPI_SCK  = PD11,
[...]
    } PinName;

#ifdef __cplusplus
}
#endif

#endif

usage:

SPIFBlockDevice spif(SPI_MOSI, SPI_MISO, SPI_SCK, EEP_CS, 1000000);

According to the datasheet and mbed reference this should work on the fly, but reality is a b****.
I found out that the Alternate Functionality Profiles are hard coded in ".\mbed-os\targets\TARGET_Silicon_Labs\TARGET_EFM32\TARGET_EFM32PG12\PeripheralPins.c" and the pins I would like to use for the SPI are mapped/pinned to the USART0, but USART0 is already used for USBTX/-RX.
So what happens inside the µC initialization:

• Serial Object (USB-Rs232) initialized on USART0.
• SPI Object initialized also on USART0 but I suggested that would be USART3, because USART0 is already in use.
• RS232 and SPI won't work because USART0 is used twice.

Ok so far so bad, for testing purposes I deleted the Alternate Functionality Profile No.17 for USART0 and added with the same pin setting to USART3 with Profile No.1 the file looks now like this:
PeripheralPins.c

From my point of view I identified the following problems ("bugs"):

• The profiles are hard coded.
• For custom targets (which I use) you can't override the "PeripheralPins.c" because the attribute __attribute__((weak)) is missing for these configuration arrays.
• The Driver does not throw an assertion when an USARTn channel is used multible times for different tasks (SPI/RS232/...).
• The Driver does not look through all profiles and does not take the next available USARTn-Channel which fits for the given pin configuration.

Issue request type

[ ] Question
[ ] Enhancement
[X] Bug

[ciarmcom]

ARM Internal Ref: MBOTRIAGE-1087

[0xc0170]

@ARMmbed/team-silabs Please review

[stevew817]

This has been a long-standing issue. In my eyes it is not a bug, but a shortcoming of how the mbed APIs map onto the Silicon Labs GPIO architecture.

I'd rather have seen mbed APIs take location numbers instead of pins, but it is what it is. As it stands, the HAL needs to figure out which peripheral a user wants to initialise based on the pins it is given. The time-space constraint tradeoff we made is to map each pin statically to a peripheral.

@DBS06 I like your suggestion about making the configuration tables weakly defined. I'll put it on the todo-list. Would that solve your immediate needs?

[DBS06]

@stevew817 making the configuration tables weakly defined would help. I already changed it locally, I can do a PR, because I would prefer to have it in the mbed-OS master and not on my local master, because of maintenance reasons.
Nevertheless I detected another issue:
I "created" my own PeripheralPins.c, basically I copied the original PeripheralPins.c to my custom target folder (without weakly define of course), it works as expected, but with mbed compile I got the following "warning-"message:

Object file PeripheralPins.o is not unique! It could be made from: .\mbed-os\targets\TARGET_Silicon_Labs\TARGET_EFM32\TARGET_EFM32PG12\PeripheralPins.c
.\ng-apps\hw_test-app\targets\TARGET_NG_DevBoard\PeripheralPins.c

Therefore I renamed my own PeripheralPins.c to i.e. PeripheralPinsDev.c
The reason for this message is somehow obvious and the linker does his job correctly, therefore the message could also be ignored, but to avoid unexpected behavior I think renaming is not the badest idea.

[DBS06]

@stevew817 I made the PR #7491. I did it for all EFM32 targets, because I assume this issue is not only for the EFM32PG12. Please look over if I maybe forgot something.