Mbed-os: nRF52832 custom target and peripheral initialization problems

[cederom]

Hello world,

I have created a custom target for my design in custom_targets.json accoring to [1]. The goal is to have common firmware repository and code for different product variants / targets based on very similar hardware.

The problem is some pins seems to be somehow already used/declared/initialized for peripherals that I am not using. For instance GPIO that I use as input is always LOW. I cannot use some pins as IRQ inputs, ADC does not show correct values, etc.

Question: How to create a target that will not have peripherals initialized or anything done in the background? I just want to select peripherals and initialize them myself..

Any hints or references appreciated :-)

[1] https://os.mbed.com/docs/mbed-os/v5.8/tools/adding-and-configuring-targets.html

Below is my custom_targets.json:

{
     "my_first_target" : {
         "inherits": ["MCU_NRF52832"],
         "release_versions": ["5"],
         "device_name": "nRF52832_xxAA"
     },
     "my_second_target" : {
         "inherits": ["MCU_NRF52832"],
         "release_versions": ["5"],
         "device_name": "nRF52832_xxAA"
     },
     "MCU_NRF52832": {
         "inherits": ["Target"],
         "core": "Cortex-M4F",
         "macros": [
             "BOARD_PCA10040",
             "NRF52",
             "TARGET_NRF52832",
             "CMSIS_VECTAB_VIRTUAL",
             "CMSIS_VECTAB_VIRTUAL_HEADER_FILE=\"cmsis_nvic.h\"",
             "MBED_TICKLESS"
         ],
         "device_has": [
             "ANALOGIN",
             "FLASH",
             "I2C",
             "I2C_ASYNCH",
             "INTERRUPTIN",
             "ITM",
             "LPTICKER",
             "PORTIN",
             "PORTINOUT",
             "PORTOUT",
             "PWMOUT",
             "SERIAL",
             "SERIAL_ASYNCH",
             "SERIAL_FC",
             "SLEEP",
             "SPI",
             "SPI_ASYNCH",
             "STCLK_OFF_DURING_SLEEP",
             "TRNG",
             "USTICKER"
         ],
        "extra_labels": [
             "NORDIC",
             "NRF5x",
             "NRF52",
             "SDK_14_2",
             "SOFTDEVICE_COMMON",
             "SOFTDEVICE_S132_FULL"
         ],
         "config": {
             "lf_clock_src": {
                 "macro_name": "MBED_CONF_NORDIC_NRF_LF_CLOCK_SRC",
                 "help": "Select Low Frequency clock source. Options: NRF_LF_SRC_XTAL, NRF_LF_SRC_SYNTH, and NRF_LF_SRC_RC",
                 "value": "NRF_LF_SRC_XTAL"
             },
             "lf_clock_rc_calib_timer_interval": {
                 "macro_name": "MBED_CONF_NORDIC_NRF_LF_CLOCK_CALIB_TIMER_INTERVAL",
                 "value": 16
             },
             "lf_clock_rc_calib_mode_config": {
                 "macro_name": "MBED_CONF_NORDIC_NRF_LF_CLOCK_CALIB_MODE_CONFIG",
                 "value": 0
             }
         },
         "OUTPUT_EXT": "hex",
         "is_disk_virtual": true,
         "supported_toolchains": ["GCC_ARM", "ARM", "IAR"],
         "public": false,
         "detect_code": ["1101"],
         "program_cycle_s": 6,
         "bootloader_supported": true
     }
 }

[cederom]

What is more I got this warning in 5.12.3 mbed compile, it seems it was not here before?

WARNING: Custom target "MCU_NRF52832" cannot replace existing target.

[ciarmcom]

Internal Jira reference: https://jira.arm.com/browse/MBOCUSTRIA-1193

[40Grit]

Refer to some of the issues I have commented on this topic. I'm @loverdeg-ep on weekdays.

In the past I recall gpios for some reason being pulled active low by default.

@trowbridgec @theotherjimmy @terminal-sc @aglass0fmilk @marcuschangarm

[cederom]

Thanks @40Grit / @loverdeg-ep that's exactly what I am experiencing right now too.. :-)

[cederom]

Hey @40Grit / @loverdeg-ep how did you overcome the pulled-low GPIO problem? I will have to solve that one too very soon.. if you have a working solution out of the box I would be more than glad to borrow it :-)

[40Grit]

Sorry, our team has been busy.

I will make a note to take a look when I get into the office today.

@farrenv

[40Grit]

Related MR https://github.com/ARMmbed/mbed-os/pull/7220

What version of Mbed OS are you targeting? Looks like 5.8 from the documentation link?

[cederom]

Thanks for reference!! The problem is still on 5.12.3, but I am using 5.9.7 at the moment because laters have full-mbed-rebuild-each-time problem..

I am initializing the pull-up while declaring the InterruptInt(). Also tried to use mode(), with no change.

One of my pins is SWO.. maybe SWO somehow disturbs the GPIO/InterruptIn? Other pins do not have this problem..

[loverdeg]

We have this implemented in our PinNames.h currently.

Still digging; design services has a way of frying neurons.

[loverdeg]

https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_NORDIC/TARGET_NRF5x/TARGET_NRF52/TARGET_MCU_NRF52840/TARGET_NRF52840_DK/PinNames.h#L254

Yes in your custom targets PinNames.h Change the default pull enum to something less assertive.

[loverdeg]

@trowbridgec This is the issue I was referencing this morning. We seem to have gone back to the default of using a PullUp in our target. Keep that in mind if we have any current issues that smell like this.

[trowbridgec]

Ah, yes you have to be careful about that. The only other way I know to set this is to use a DigitalInOut and use the mode() function.

[cederom]

So far I have identified following problems:

• P0.18/SWO is always 0. Can be used as InterrputIn but always reads 0.
• P0.22, P0.24, P0.28/AIN4. Cannot be used as InterruptIn - causes crash.

I am using PullUp as default in PinNames.h:

typedef enum {
    PullNone = 0,
    PullDown = 1,
    PullUp = 3,
    PullDefault = PullUp
} PinMode;

In 5.9.7 system hangs. In 5.12.3 I get into mbed_die() when using one of P0.22, P0.24, P0.28/AIN4 as InterruptIn.

[40Grit]

Check errata? It was probably one of the Atmel samd parts, but I recall being bitten by or reading about a gpio pull issue on a P22,P24 before.

[40Grit]

Also try the bare metal profile to limit any potential for weirdness and semihost your debug terminal?

[cederom]

Well, this is the bare metal :-) Errata should be implemented in mbed I guess.. will read.. thanks for hint @40Grit ! :-)

[evedon]

This is a useful discussion. Please consider contributing a PR.

[cederom]

work in progress.. kinda logbook here.. there is a chance that my own configuration of the target is invalid and cannot simply copy some components from an existing configuration.. I have noticed that 5.9 and 5.12 builds, but for instance 5.10 is more strict about Target configuration (unless a bug in release itself).. eventually we will find out make a PR and DOC updates :-)

[trowbridgec]

Just a note, similar strange behavior with the GPIO was noted with Cordio on the nRF52840 (see #10321), and the fix was an update to the Cordio link layer (#10542). I see you're using SoftDevice, so it may or may not be related?

[cederom]

What I noticed, MBED has its own API, then it uses HAL, then it uses some glue functions, then uses NORDIC SDK. So the problem may also be introduced somewhere in the Glue or SDK. Will have to figure that out and make some more detailed documentation. Using MBED on DevelKit is nice, but using MBED on a custom product is more important :-)

[loverdeg]

@cederom I think you are right as I still have some corrupted memories of finding the root cause of this somewhere in NRF SDK.

[cederom]

..and below the SDK there is the SoftDevice.. thanks for sharing the possible issues with radio stacks interfering with the GPIO.. looks like fun =)

[0xc0170]

@cederom is there anything new to this issue, should we close it if not?

[cederom]

I will try with Cordio BLE Stack that is default in 5.13 maybe that will solve the issue :-)

In general there would be really nice if we had a Porter's Handbook where full description of the Custom Target would be presented :-)

We can close it for now as there seem no solution at the moment. If I have more specific questions I will reopen here or create new more detailed issues.

Thank you for your support and time! :-)