Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: Nano 33 BLE #407

Open
wants to merge 8 commits into
base: master
from
Open

WIP: Nano 33 BLE #407

wants to merge 8 commits into from

Conversation

@rpavlik
Copy link

rpavlik commented Jan 6, 2020

Per adafruit/Adafruit_nRF52_Bootloader#94 and adafruit/Adafruit_nRF52_Bootloader#97 I'm interested in using the UF2 bootloader on my Nano 33 BLE. I got it working, though the stock Arduino board def uses bossac, which doesn't work with the adafruit NRF52 bootloader. To adjust for this, I added a new board in this board collection to use nrfutil dfu. The pin definitions are based on the original (though ported to this repo's technique), most everything else is related to or based on the Itsy or Feather nrf52832 definitions.

I have successfully run several Adafruit BLE demos, including the "Controller" example where adding these lines to the color packet handler lets you control the onboard RGB LED using the Bluefruit app:

    analogWrite(LEDR, 255 - red);
    analogWrite(LEDG, 255 - green);
    analogWrite(LEDB, 255 - blue);

No idea if there's appetite for merging this, but I figured I'd share and submit it at the very least.

@ladyada

This comment has been minimized.

Copy link
Member

ladyada commented Jan 7, 2020

thanks! this is cool, and we want to make sure we match folk's expectations.
would you be ok adding a readme.md on how people load the bootloader on and renaming this to "Arduino Nano 33 BLE (Unsupported)"? that way we dont end up with confused folks who dont realize you need a jlink to load the bootloader before starting! :)

@rpavlik

This comment has been minimized.

Copy link
Author

rpavlik commented Jan 7, 2020

Glad you like it! I've pushed my latest commits, which include a README in the bootloader directory. I also tested flashing back to the original bootloader, which worked great with my Atmel-ICE - flashing the Adafruit bootloader also worked great, so those are the instructions I used. Pretty sure there are some open-source CMSIS-DAP programmer firmwares out there, so should be accessible for those with the technical skills.

I do have some photos of my (hacky) pogo pin jig that I haven't added yet, let me know if you think they'd be useful. (You can put a mechanical-only pogo pin 2 holes away from either side of the electrically-useful ones to go into the actual header holes for alignment, which is handy if you have a no-header version of the board. Today I didn't even clamp it when doing the bootloader since I had it down to a single command I could send with one hand.)

@ladyada

This comment has been minimized.

Copy link
Member

ladyada commented Jan 7, 2020

yeah add any pics you like :) when you're done we'll do a final review

@henrygab

This comment has been minimized.

Copy link
Collaborator

henrygab commented Jan 12, 2020

@rpavlik Hi Ryan,

I was taking a look at the Nano 33 BLE board, but it appears that the official docs disagree on D7 and D8. Specifically, the official board pinout diagram shows D7 is P0.09, and D8 is P0.10. However, the official Arduino BSP v1.1.3 variant.cpp says they are 0.23 and P0.21, respectively:

https://github.com/arduino/ArduinoCore-nRF528x-mbedos/blob/8b642cc27b7056029357ca1c63d20bd9435ea40c/variants/ARDUINO_NANO33BLE/variant.cpp#L12-L15

Your commits appear to follow the BSP. Can you verify that D7 and D8, when mapped to P0.23 and P0.21 respectively as in your commits, will work in blink sketch targeting D7 / D8?

If an LED doesn't blink on D7/D8 as-is, can you try again after adjusting variant.cpp to have D7 / D8 at P0.09 / P0.10, respectively?

Thanks!

@rpavlik

This comment has been minimized.

Copy link
Author

rpavlik commented Jan 12, 2020

Good catch! I'll have to solder in the headers and try that one out. Pretty sure it's not the first inconsistency I've seen in the docs.

@henrygab

This comment has been minimized.

Copy link
Collaborator

henrygab commented Jan 15, 2020

@rpavlik -- Well, they updated the picture to match the variant files. So, no need to change pins at this point. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.