3 years ago.

pin=NC causes system halt, is the intented?

Checking the source files I found that all "pin_function" and "pin_mode" functions in the pinmap.c files contain following statement

<<code>> MBED_ASSERT(pin != (PinName)NC); <</code>>

This causes a program halt in any case that pin=NC. That shoudn't be intention, should it?

Question relating to:

mbed official / mbed Featured
The official mbed C/C++ SDK provides the software platform and libraries to build your applications.

Thanks, Uwe

posted by Uwe Haertel 10 Sep 2014
Comment on this question

3 Answers

3 years ago.


just checked that it's in pinmap.c for any given target. But that's the intented behaviour. pin_mode(PinName pin, PinMode mode) pin_function(PinName pin, int data)

require valid pin to operate on. NC is Not connected, you can not set it's function or mode. So the assert catches the wrong parameter and helps you fix the bug.

have fun, alex

No, I don't agree. In former versions of mbed lib it used to be possible to declare unused pins as NC, f. i.

<<code>>SPI spi(p5, NC, p7) <</code>>

in case of an output only spi, to use p6 for something else. This code doesn't work anymore.


posted by Uwe Haertel 10 Sep 2014

It should be but if you are hit by the assert there is a BUG somewhere else in the code. Looking at the SPI code it should work. It uses pinmap_pinout(PinName pin, const PinMap *map) and have a check to skip configuration of the NC pins. What target are you using?

posted by alex atanasov 10 Sep 2014

I use a LPC1768.

I have two statements in my code with an "NC" that causes the ASSERT failing message. One is the SPI declaration, the other is an output only serial interface: Serial si(p28, NC); With older revisions of mbed lib (<=80) it used to work.


posted by Uwe Haertel 10 Sep 2014

The problem is at serial_init.c


diff --git a/libraries/mbed/targets/hal/TARGET_NXP/TARGET_LPC176X/serial_api.c b/libraries/mbed/targets/hal/TARGET_NXP/TARGET_L
index 7972eda..161089a 100644
--- a/libraries/mbed/targets/hal/TARGET_NXP/TARGET_LPC176X/serial_api.c
+++ b/libraries/mbed/targets/hal/TARGET_NXP/TARGET_LPC176X/serial_api.c
@@ -120,8 +120,12 @@ void serial_init(serial_t *obj, PinName tx, PinName rx) {
     pinmap_pinout(rx, PinMap_UART_RX);
     // set rx/tx pins in PullUp mode
-    pin_mode(tx, PullUp);
-    pin_mode(rx, PullUp);
+    if (tx != NC) {
+           pin_mode(tx, PullUp);
+    }
+    if (rx != NC) {
+           pin_mode(rx, PullUp);
+    }
     switch (uart) {
         case UART_0: obj->index = 0; break;

You can try this patch.

posted by alex atanasov 10 Sep 2014

That alone won't fix it, the other issue is the pin_function which will be called (granted pin_mode is also a problem). You do have a point that it shouldn't call those functions in the first place if the pin isn't connected, on the other hand even though it needs to be fixed on all targets, I think it is easier and less prone to errors to handle it in the pin_function and pin_mode functions, than in the SPI and UART functions (I think those two are affected, since the only other multi-pin library is I2C, and using that with one pin as NC makes very little sense).

posted by Erik Olieman 10 Sep 2014

I simply have substituted the ASSERT statement in the "pin_function" and "pin_mode" functions bei

<<code>> if (pin == NC) return; <</code>>

in the pinmap.c for my plattform. This should solve all possible problems with NC pins.

Bests, Uwe

posted by Uwe Haertel 11 Sep 2014

By the way: is it possible to get the source files of the former revisions ( e.g. #79) of the mbed lib. I'd like to see how it was coded there, when it used to work.

posted by Uwe Haertel 11 Sep 2014

Okay, I did some research and found that until #226 of the mbed-src both function in the pinmap.c where coded exactly like this (if (pin == NC) return;) From #227 the MBED_ASSERT macro has been introduced insteed, not regarding all consequences.

In the mbed lib in version #86 the MBED_ASSERT macro was offically introduced, but is documented only for the gpio_read and _write functions not für pin_function and pin_mode.


posted by Uwe Haertel 11 Sep 2014
4 months, 1 week ago.

Hi! Sorry to reactivate this old thread, but is this still unresolved?

I use the library and it halts wehn i use NC for some unused pins (reset,cs).

UC1608 myLCD(SPI_16, 10000000, p11, p12, p13, NC, NC, p16,"myLCD", 132, 64); // Spi 16bit, 10MHz, mosi, miso, sclk, cs, reset, dc

No lights of death, nothing! When i define any other pin for it, it works!

Why doesn't NC work anymore for SPI, DigitalOut?


thats the same as my Problem: a NC pin must not be set. So for example like in protocols/spi8.cpp:

SPI8::SPI8(int Hz, PinName mosi, PinName miso, PinName sclk, PinName CS, PinName reset, PinName DC)
    : _CS(CS), _spi(mosi, miso, sclk), _reset(reset), _DC(DC)
    _reset = 1;

must check the optional Signal first:

if (reset != NC)
  _reset = 1;
posted by Johannes Stratmann 18 May 2017

Hi! Is this considerd as a bug? If not, a lot of packages have to be changed. Is there an easy workaround? Using other pins is no good solution for me.

What is the MBED_ASSERT good for? Just stop the program without any notification???

posted by Karl Zweimüller 19 May 2017
2 years, 10 months ago.

Now I ran into the same problem. I use a graphics lib and my hardware has no reset pin, it was ok to call the constructor of the display with 'nc' for the reset pin. With an updated mbed lib I get now also the assertion and I'm not sure at which level I have to fix the problem. Is there any discussion in the forum about this subject?

As I have mentioned in version #86 the MBED_ASSERT macro has been introduced in the mbed lib. Thus, you can either use an older Version of the lib or you can do like me and use the source and modify the code or you write an unused pin number instead of NC. I do not understand this massive encroachment in the library that leads to system halt after recompilation of ! working code ! It seems there is some confusion in the management of library coding - not really professionally.

posted by Uwe Haertel 16 Nov 2014

full ACK, the goal for new lib releases should be to maintain the comaptibility. Allowing a NC for a pin is a basic feature, changing this makes the NC constant senseless. I'm a stupid user, I don't want to freeze my project with a special lib version and I don't want to use a private modified version. Other users will run into the same problem when you have to use an older or special mbed version :-(

posted by Johannes Stratmann 16 Nov 2014

Hello, can you describe your use of NC pin? there might be a missing condition for the target or your case is not covered. Please provide me details, I can look at it and see what we can do.

posted by Martin Kojtal 17 Nov 2014

thanks for your help, I published my test project here: In line #14/15 you see the working and not working use of NC. The target is a LPC1347 board, EzSbc2. It is not an original mbed board, so don't care the pin names.

posted by Johannes Stratmann 17 Nov 2014

To post an answer, please log in.