neopixels on the nRF52840

I was playing around with the PAN1780 eval kit (it mimics the nRF52840DK closely except for the lack of QSPI) and I seem to have issues with neopixel.

Has anyone been able to get an nRF52840 working with neopixels? Doing something like

require("neopixel").write(D28, [255,0,0]);

seem to lock up the board. The web ide console (connected through ble) stops responding, and a blinky I have running to check if the board was still actually working behind the scenes stops blinking. It doesn't seem to matter whether I have a neopixel connected or not.

Here's what I use for testing this:

let on = 0;

const toggle = () => {
  on = !on;
  digitalWrite(LED1, on);
};

setInterval(toggle, 100);  

setTimeout(()=>{
  require("neopixel").write(D28, [255,0,0]);
}, 1000);

I have an actual nRF52840DK arriving sometime next week so I can see if it's just this particular board that's the problem, but I wanted to see if anyone has had success with neopixels on any kind of board that has the nRF52840 (like the particle boards for example)

I haven't tried, but it should work. Just as a test, any luck using a different pin?

I'll try it out, sorry I'll need to be on a few calls but I'll get back soon :)

FWIW I tried it on a different nRF52840 board (the waveshare eval kit) and it locks up as well.

So far I've tried D2, D3, D26, and D27 and they all lock up :( I've also changed the led toggle so it ends up on by the time the neopixel call happens, and the led stays on when it locks up (suggesting that it is indeed locked up and not just a broken console connection).

It's not urgent though, but I'm doing a road test of the PAN1780 eval kit for Element14 and one of the things I wanted to showcase its BT capabilities was doing some light shows with neopixels. I can always do something else instead (like the home automation I'm currently running with the Puck and EpsruinoHub and Tasmota, but this time with the extra TX power available with the nRF52840).

Sat 2020.10.03

Hi @parasquid, no experience with the nRF52840DK and as there are many variants:

REFERENCE table of RGB Led datasheets 3528 5050 WS2811 WS2812 SK6812 APA102 NeoPixel

Taking into consideration: (in case this statement is found inaccurate)

'It doesn't seem to matter whether I have a neopixel connected or not'

Some ideas to explore:

Is there a level shifter, or is a level shifter required? (several in link above)

Separate supply and grounding consideration

Any possibility of a Neopixel strip of several LEDs to rule out flaky first green LED issue

https://www.reddit.com/r/arduino/comments/499ods/strip_of_144_ws2812b_leds_first_led_stuck_green/

that along with RGB vs GRB and leading start pulse duration

Pull-up on data line (see reference in reddit link)

Any ability to try a different Neopixel type? Some are 12V, different gating, end pulse state?

What is driving the Neopixel? Regulator on that board, or separate supply?

Try writing a larger array, to rule out rounding of starting pulse (which causes first green LED, BTW)
[055,055,055, 055,055,055, 055,055,055, 055,055,055])
Smaller value to reduce load on regulator, and all lit to see if pulse rounding issue is resolved

Ability to use Logic Analyzer to validate data sent?

EDIT:   (see post #7 explanation - now built in)
Could there be a module retrieval delay that is beyond the 1 second timeout interval shown?

FWIW: I've always assigned the results of the require to a separate object after init, and performed future array writes in separate functions after a three second wait. Always successful on Pico, Wifi and MDBT42Q when using a level shifter.

The neopixels work on the same board when using Adafruit's Arduino core so I don't think it's the circuit nor the neopixels itself.

1 Attachment

Thanks for the image. So the above with Arduino uses a longer array to write out the eight colors. was that suggestion tried? (ref larger array)

And we confirm on board regulator is sufficent to drive 8 Neopixels using Arduino code block? (Yes?)

'I don't think it's the circuit nor the neopixels itself.'

Would have to agree (for #6 image - is that an Arduino and not the DK board?):

EDIT: But the link in #8 post is to a different board that what is shown in #6 image

EDIT:
Are we able to rule out the delay fetching the module across the web?

I may have to eat crow on that one. I just took a look at some working code from two years ago, and I used the require within a function call. I've also re-read my notes and just realized the Neopixel module is now a part of the current release, so it isn't (now) fetched across the web as it was when I developed then.

That strip seems to the the WB2812B and pretty common and easy to work with.


FWIW: I had a heck of time many months ago, until I could confirm squaring up of the data line with a level shifter, and the correct leading start pulse length. I don't know the nRF52840DK and that may not even be a consideration as it is confirmed with the Arduino #6 post image.

Hello Robin, this is the another board with the nRF52840 that I'm using with Espruino. It has an nRF52840 chip (the bigger brother of the nRF52832 chip that can be found on the MDBT42Q). The chip can be programmed with multiple frameworks: MicroPython, Arduino, Mbed, Zephyr, and of course our beloved Espruino.

I am not sure what you mean by the Arduino code block image. When I use Arduino as the framework, the neopixels work. When I flash Espruino on the same board, the board locks up as soon as it hits the neopixel statements.

This is the nRF52840DK https://www.nordicsemi.com/Software-and-Tools/Development-Kits/nRF52840-DK it is the reference development board for the nRF52840 chip by Nordic Semi.

'I am not sure what you mean by the Arduino code block image.'

Was referencing your #6 image. Our posts crossed and I didn't get the correction done by the time your follow-up came through.


What pinMode() is used?

The ideas were worth a shot. It does seem odd though that the board just locks up. The additional image, links, verification and testing is helpful and should assist others.

It appears you are the pioneer (def pioneer: the guy with all the arrows in his back) here with the nRF52840DK.

Hey Robin, it's alright I think I got it working. Thanks for bringing up the topic, otherwise I would have just given up. I even used your [055,055,055, 055,055,055, 055,055,055, 055,055,055] test (which lights up all pixels white btw, no green led for me).

@Gordon it looks like LRCK is required to be defined, aside from SCK. I found a discussion on the nordic forums here: https://devzone.nordicsemi.com/f/nordic-q-a/55802/driving-ws2812b-neopixels-with-i2s-without-sck-lrck

Doing something like:

@@ -45,7 +45,7 @@ ret_code_t i2s_ws2812b_drive_xfer(rgb_led_t *led_array, uint16_t num_leds, uint8
 [#else](https://forum.espruino.com/search/?q=%23else)
        config.sck_pin      = 22;
 [#endif](https://forum.espruino.com/search/?q=%23endif)
-       config.lrck_pin     = NRF_DRV_I2S_PIN_NOT_USED;
+       config.lrck_pin     = 23;
        config.mck_pin      = NRF_DRV_I2S_PIN_NOT_USED;
        config.sdout_pin    = drive_pin;
        config.sdin_pin     = NRF_DRV_I2S_PIN_NOT_USED;

gets everything working.

I haven't tested and compiled with the nRF52832 boards with LRCK defined though, so I'm not sure if that would affect any of the functionality of the official boards.

Edit: the forum seems to mess up the diff, so here's a screenshot

1 Attachment

@parasquid Ok, so you build Espruino for BOARD=NRF52840DK

The neopixel lib and the nRF5x code for ws2812b are the same, but NRF52840DK is using the SDK 15.

@MaBe yes, the boardfile already specifies SDK15 but I'm not sure if that affects neopixels.

Hmm looking at the targets, it seems that the nrf5x are custom code that applies to the nrf5x family, and that includes the i2s neopixel drivers.

At least for now I've got it working on the nRF52840 board I have; I'll have to try compiling for the nRF52832 based boards and see if specifying the LRCK pin on i2s would break anything (hopefully not).

I also chose D23 since the other boards (notably MDBT42Q) are choosing that, instead of the default D22. I thought that should minimize any breaking changes.

Anyway, thanks again @Robin and @MaBe for the support :)

But it could, Espruino is using this version for SDK15

https://github.com/espruino/EspruinoBuildTools/tree/master/nrf52

So check if there is a new version or some new patches ;-)

Got it, I'll see if there are any. Didn't realize there was this repo, this is the one referenced in the provision.sh script isn't it?

yes it is :)

repsonse to #14 post and #4 requirement

'I'm doing a road test of the PAN1780 eval kit for Element14 and one of the things I wanted to showcase its BT capabilities was doing some light shows with neopixels.'

'I can always do something else instead . . . '

Sometimes just taking a bit of time off, asking the right questions, then overturning that one last stone enables one to find the treasure!

'doing something else' seemed like a load of extra work, and besides who doesn't like bright colored moving lights as a showcase demo to spark a conversation!!

Glad your persistence located the tid-bit of needed info to resolve. . . .

Glad you got this sorted! I just pushed a change for this, so if you add -DNEOPIXEL_LRCK_PIN=23 to your BOARD.py then you can get it working with standard firmware.