Using an unbonded pin in the device tree

Background:

My project is using the nrf54L15 with the 48 pin package.  I'm using vscode with v3.2.0. The QFN48 package has the following pins bonded from the silicon to the exterior of the package:

P0.00 - P0.04

P1.00 - P1.14

P2.00 - P2.10

I am using every pin for my application.  I need one more pin.

Specifics:

One part of my application, is driving a SK6812 LED array.  My current pin assignment is:

   i2s20_default: i2s20_default {
        group1 {
            psels = <NRF_PSEL(I2S_SDOUT,  1, 14)>,
                    <NRF_PSEL(I2S_SCK_M,  1,  4)>,
                    <NRF_PSEL(I2S_LRCK_M, 1,  7)>;
        };
    };

And this works fine.  I can see the pixels working as expected.  I only need pin P1.14 to drive the LED array.  Pins P1.04 and P1.07 are not connected to any part of my circuit... thereby being wasted.   I have tried setting the pins to 

            psels = <NRF_PSEL_DISCONNECTED(I2S_SCK)>,
                    <NRF_PSEL_DISCONNECTED(I2S_LRCK)>,

but then the I don't get the output driving the LED array. (does not work).

Experiment:

I found that if I map one of the unneeded clock pins to P1.15 (not in the range that is exposed on the IC) such as:

    i2s20_default: i2s20_default {
        group1 {
            psels = <NRF_PSEL(I2S_SDOUT,  1, 14)>,
                    <NRF_PSEL(I2S_SCK_M,  1, 15)>,
                    <NRF_PSEL(I2S_LRCK_M, 1,  7)>;
        };
    };

I free up P1.04.   The LED array works as expected.  Furthermore, when I map the second unneeded pin to P1.16, such as:

    i2s20_default: i2s20_default {
        group1 {
            psels = <NRF_PSEL(I2S_SDOUT,  1, 14)>,
                    <NRF_PSEL(I2S_SCK_M,  1, 15)>,
                    <NRF_PSEL(I2S_LRCK_M, 1, 16)>;
        };
    };

The LED array still works as expected.

Question:

Is there any issue with using P1.15, and P1.16 in this fashion on the QFN48?  I will not be wiring the I2S_SCK_M nor I2S_LRCK_M to anything, and mapping these two pins to P1.15 and P1.16 frees up 2 pins which can be used for something else. 

I see that the 52 pin package of the same chip exposes pins P1.00 - P1.16.  This tells me that the silicon supports pins P1.15 and P1.16, but does not expose them for the QFN48 package.

Are the pins P1.15 and P1.16 used for any other internal purpose in the QFN48 pin package?

Parents Reply Children
  • Hello,

    If you configure a pin out of physical range, PSEL points to a non‑existing pad. It’s treated as a legal configuration that map to “no effective pin”. There’s no hardware check on this violation. Validation is only done on the SW side such as SDK pinmaps, devicetre.. Basically, no direct risk of damaging the chip just from selecting a non‑existing pad via PSEL.

    Kenneth

  • Thank you, Kenneth-

    I will assume that the pins are not used for any internal purpose.  As long as i can select P1.15 and P1.16 in the device tree, i will use these as dummy connections in the above specified manner. 

    I did manage to free up 2 other pins in my solution as a backup plan. I will start out using P1.15 and P1.16 as described above for our EVT run and switch to the freed pins if needed.

    -Peter

Related