You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When attempting to initialize UART1 on certain pins (see below), instead UART0 is initialized to these pins, because they are present in PinMap_UART_TX and PinMap_UART_RX (in PeripheralPins.c) as UART_0 before the UART_1 entry.
AFFECTED PINS (These are all pins that can function as either UART0 or UART1, and thus, cannot actually function as UART1)
pinmap_peripheral() does a simple scan through the passed array (here, PinMap_UART_TX and PinMap_UART_RX), starting from the first index.
Therefore, for pins 39 and 40, it will always select UART0, because that is what is present in the array first.
Furthermore, because the Arduino core caches the mbed OS, it is NOT sufficient to simply comment out those lines or change the file, as it will not be recompiled. A full recompile of the mbed OS is necessary, but this is a complete hack when working with Arduino.
Target(s) affected by this defect ?
All; this issue is present in the TARGET_APOLLO3/device folder, which seems to take effect for any Apollo 3 sub-target.
How is this defect reproduced ?
Attempt to initialize UART1 on any of the above pins. The pins will instead be initialized as UART0.
Possible Solutions
I can think of a few ways to solve this issue, though I must admit: I'm quite new to this codebase, and I've been struggling with this problem for weeks. It took me a long time to find the actual issue because it's just... a lot to familiarize myself with. I say this just to indicate that I'm likely missing a very obvious, natural way to fix this.
Proper BSP usage
It seems that right now, the BSP for any individual target is being used in multiple places, its definitions referenced (manually?) in others, and is being (almost completely?) overruled by the following files in TARGET_APOLLO3/device:
PeripheralPinConfigs.c/h
These seems to be am_bsp_pins.c/h with no changes to content
PeripheralPins.c
This seems to be a manually-written bridge between Mbed and Apollo3, written specifically against PeripheralPinConfigs, as opposed to the developer-provided BSP
These seem to be the files that actually dictate the BSP that is used by mbed OS, and it's a BSP that seems to be "every pin can do everything it can do". Which seems reasonable, except for bugs like this.
Is there an easy way to allow developers to provide their own BSP? It's possible now, but you need to recompile the mbed os library. Currently, I'll need to maintain a fork of this library to use my own BSP.
The text was updated successfully, but these errors were encountered:
UbiJCC
changed the title
UART interface cannot be initialized if lower-numbered interface shares a pin
UART initialization chooses incorrect interface if lower-numbered interface shares a pin
Dec 31, 2020
Hello,
I am having the same issue and after a couple of days struggling I came across your post.
Still trying to figure out how to fix it.
Will update if I manage...
Massimo
Description of defect
When attempting to initialize UART1 on certain pins (see below), instead UART0 is initialized to these pins, because they are present in
PinMap_UART_TX
andPinMap_UART_RX
(inPeripheralPins.c
) as UART_0 before the UART_1 entry.AFFECTED PINS
(These are all pins that can function as either UART0 or UART1, and thus, cannot actually function as UART1)
PeripheralPins.c:
This happens because in
serial_api.c
, insideserial_init(...)
, the UART interface to initialize is determined by the following code:serial_api.c:
pinmap_peripheral()
does a simple scan through the passed array (here,PinMap_UART_TX
andPinMap_UART_RX
), starting from the first index.Therefore, for pins 39 and 40, it will always select UART0, because that is what is present in the array first.
Furthermore, because the Arduino core caches the mbed OS, it is NOT sufficient to simply comment out those lines or change the file, as it will not be recompiled. A full recompile of the mbed OS is necessary, but this is a complete hack when working with Arduino.
Target(s) affected by this defect ?
All; this issue is present in the
TARGET_APOLLO3/device
folder, which seems to take effect for any Apollo 3 sub-target.How is this defect reproduced ?
Attempt to initialize UART1 on any of the above pins. The pins will instead be initialized as UART0.
Possible Solutions
I can think of a few ways to solve this issue, though I must admit: I'm quite new to this codebase, and I've been struggling with this problem for weeks. It took me a long time to find the actual issue because it's just... a lot to familiarize myself with. I say this just to indicate that I'm likely missing a very obvious, natural way to fix this.
Proper BSP usage
It seems that right now, the BSP for any individual target is being used in multiple places, its definitions referenced (manually?) in others, and is being (almost completely?) overruled by the following files in
TARGET_APOLLO3/device
:PeripheralPinConfigs.c/h
am_bsp_pins.c/h
with no changes to contentPeripheralPins.c
PeripheralPinConfigs
, as opposed to the developer-provided BSPThese seem to be the files that actually dictate the BSP that is used by mbed OS, and it's a BSP that seems to be "every pin can do everything it can do". Which seems reasonable, except for bugs like this.
Is there an easy way to allow developers to provide their own BSP? It's possible now, but you need to recompile the mbed os library. Currently, I'll need to maintain a fork of this library to use my own BSP.
The text was updated successfully, but these errors were encountered: