Nordic nRF52 DK Issues

[screamerbg]

Description

• Type: Bug
• Priority: Major

---

Bus failures (BusInOut)

BusInOut doesn't work correctly in the following scenario:

• Digital loops D2-D3, D4-D5, D6-D7, D8-D9
• BusInOut-1 initialized for D2, D4, D6, D8
• BusInOut-2 initialized for D3, D5, D7, D9

Writing to BusInOut-1 do not produce same read values BusInOut-2 although pins are looped.
Example test program here: https://github.com/ARMmbed/ci-test-shield/blob/master/TESTS/API/BusInOut/BusInOut.cpp
See below for schematics

Pwm failures (PwmOut) - ARMCC

Assert error while trying to initialize PwmOut on D3, D5, D6, D9 (as per Arduino header standard)

Analog In failures (AnalogIn) - ARMCC

Analog Input on A0
Analog Input on A1
Analog Input on A2
Analog Input on A3
Analog Input on A4
Analog Input on A5

Tests available here https://github.com/ARMmbed/ci-test-shield/blob/master/TESTS/API/AnalogIn/AnalogIn.cpp
See below for schematics.

Target
NRF52_DK

Toolchain:
ARM

meed-os sha:
08ff689 Merge pull request #2979 from adustm/STM_F429_F439

Steps to reproduce
Tests available here https://github.com/armmbed/ci-test-shield
Hardware components here https://github.com/ARMmbed/mbed-HDK/tree/master/Production%20Design%20Projects/CITestShield

Note that tests are based on Arduino header connectivity standard. More information available here:

CC @pan- @nvlsianpu

[pan-]

@screamerbg Did you ground the DETECT pin before running the tests ?

The NRF52_DK use an I/O expander to avoid conflicts between an Arduino shield and the NRF52_DK buttons and LEDs.

To detect that an Arduino shield is present, the NRF52_DK use the GND signal from the ICSP block of an arduino shield.
The mbed test shield like many other shields does not expose the ICSP block.
In that case, the pin DETECT (on the NRF52_DK) should be grounded manually to disable the I/O expander and release LEDs and buttons GPIOs.

[nvlsianpu]

@screamerbg Regards PWM failures - on NRF52 target up to 3 PWM instances simultaneously are supported. So test didn't fit target constraints.
In this test case 4 instances of PWM are created. For 4-th instance assertion will occur due to that the target support 3 PWM.

[nvlsianpu]

cc @anangl

[nvlsianpu]

#3106 is a blocker for this issue.

[0xc0170]

#3106 is a blocker for this issue.

Can you be more specific? I am interested mainly if this is an issue for any platform , or that blocker is active just for nordic because of some specific reasons.

[nvlsianpu]

In issue #3106 was described how analogue and digital shared hardware resources interact each other for nRF5x. I'm sure that there are similar cases for most of uC. Shared resources like shared I/O are incorporated in many SoC. Of course there is possible to fix this internally for Nordic but, it will be a patch whit only applied to Nordic and will add significant complication (each of nordic mbed hal driver implementation should then looks for other driver...)

[ghost]

GitHib issue review: Closed due to inactivity. Please re-file if critical issues found.