8000 ports/nrf: Add support for Arduino Nano 33 BLE board. by iabdalkader · Pull Request #8577 · micropython/micropython · GitHub
[go: up one dir, main page]
Skip to content

ports/nrf: Add support for Arduino Nano 33 BLE board. #8577

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.

Sign up for GitHub

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

Jump to bottom
Closed
wants to merge 4 commits into from
Closed

ports/nrf: Add support for Arduino Nano 33 BLE board. #8577

wants to merge 4 commits into from

Conversation

iabdalkader
Copy link
Contributor
@iabdalkader iabdalkader commented Apr 22, 2022 •
edited by dpgeorge
Loading

@iabdalkader iabdalkader force-pushed the arduino_nano_33_ble branch 6 times, most recently from 0f68dab to c7686c1 Compare April 27, 2022 08:06
@iabdalkader iabdalkader changed the title Add support for Arduino Nano 33 BLE board. ports/nrf: Add support for Arduino Nano 33 BLE board. May 11, 2022
@iabdalkader iabdalkader force-pushed the arduino_nano_33_ble branch from c7686c1 to 3ad1cc3 Compare June 9, 2022 10:28
@iabdalkader iabdalkader force-pushed the arduino_nano_33_ble branch from 3ad1cc3 to 2767333 Compare June 17, 2022 06:46
dpgeorge
dpgeorge reviewed Jun 23, 2022
View reviewed changes
@dpgeorge
Copy link
Member

We need to think of a way to manage the device drivers. They are generic so better to place them in drivers/ rather than in the board directory. Also, their methods need to be somewhat consistent across the different drivers. This needs some thought and discussion, see eg #2093 and #3218. Also #3256 should be considered.

@iabdalkader iabdalkader force-pushed the arduino_nano_33_ble branch from 2767333 to 43375a8 Compare June 27, 2022 11:35
@iabdalkader
Copy link
Contributor Author

We need to think of a way to manage the device drivers. They are generic so better to place them in drivers/ rather than in the board directory. Also, their methods need to be somewhat consistent across the different drivers.

I agree, but I think that's beyond the scope of this PR, and should be discussed further as part of the larger MicroPython drivers/modules/repo discussion. That said, I can move the sensor drivers to /drivers if you want.

dpgeorge
dpgeorge reviewed Jul 5, 2022
View reviewed changes
@dpgeorge
Copy link
Member
dpgeorge commented Jul 5, 2022

I agree, but I think that's beyond the scope of this PR, and should be discussed further as part of the larger MicroPython drivers/modules/repo discussion. That said, I can move the sensor drivers to /drivers if you want.

Yes it is out of scope to solve the problem of drivers here. But I think it would be good to put them in drivers/ as straightaway (as part of this PR), at least so they are all collected there and we can get a feel for what must be moved when the time comes.

@iabdalkader
Copy link
Contributor Author

But I think it would be good to put them in drivers/ as straightaway (as part of this PR)

Done!

@iabdalkader iabdalkader force-pushed the arduino_nano_33_ble branch from 43375a8 to 71caea9 Compare July 5, 2022 20:23
@iabdalkader iabdalkader force-pushed the arduino_nano_33_ble branch from 71caea9 to 542b992 Compare July 5, 2022 20:27
@dpgeorge
Copy link
Member
dpgeorge commented Jul 7, 2022

Rebased and merged in fc6d989 through 5c31a6c (and I moved the drivers to individual subdirectories, to match other drivers).

@dpgeorge dpgeorge closed this Jul 7, 2022
@iabdalkader iabdalkader deleted the arduino_nano_33_ble branch July 7, 2022 14:10
@iabdalkader
Copy link
Contributor Author

@dpgeorge I think I made a small typo here after removing lambda, should have removed the call here:

self._go_idle = machine.idle()

To

self._go_idle = machine.idle

@dpgeorge
Copy link
Member
dpgeorge commented Jul 7, 2022

Yes, that will need to be fixed.

But, maybe it's better to implement machine.idle() on nrf so this part is not even needed? Even if machine.idle() did nothing, or did mp_hal_delay_ms(1), that would be a good start.

@iabdalkader
Copy link
Contributor Author

There's a WFI that's actually called from sleep and deepsleep.

@iabdalkader
Copy link
Contributor Author

#8880

FYI, while (True) loops can't be interrupted with ctrl+c, I think that's the same issue that was fixed in rp2 port.

@iabdalkader
Copy link
Contributor Author

Yes, sorry I forgot, you need to make usb_cdc_loop not static.

@robert-hh
Copy link
Contributor
6D40 robert-hh commented Jul 9, 2022

That wasn't my topic. usb_cdc_loop() only exists for devices which have MICROPY_HW_USB_CDC set. For all other devices, this fuction does not exist. So I extended mpconfigport.h a little bit. Like Makefile, this file tends to grow in an ugly way.
I updated my branch in nrf_ctrl_c, so it's ready for another test. You could as well try to remove the changes to mpconfigport.h.

@iabdalkader
Copy link
Contributor Author
iabdalkader commented Jul 9, 2022 •
edited
Loading

@robert-hh I see now what you mean. I think it's best if you follow rp2 port's mpconfigport.h:

#if MICROPY_HW_ENABLE_USBDEV
#define MICROPY_HW_USBDEV_TASK_HOOK extern void usb_cdc_loop(void); usb_cdc_loop();
#else
#define MICROPY_HW_USBDEV_TASK_HOOK
#endif

EDIT There's no MICROPY_HW_ENABLE_USBDEV in nrf port, but maybe test for MICROPY_HW_USB_CDC

@robert-hh
Copy link
Contributor

That's what I did, and it compiles for both board types. You can run a test now with the actual nrf_ctrl_c branch. I wonder if the changes to mpconfigport.h are actually required.

@iabdalkader
Copy link
Contributor Author
iabdalkader commented Jul 9, 2022 •
edited
Loading

Tested, seems to be working fine.

I wonder if the changes to mpconfigport.h are actually required.

Yes they are, for example when call time.sleep_ms, although you can just call tud_task instead of the usb_cdc_loop
.

@robert-hh
Copy link
Contributor

Thank. I want to make the minimal change. So I changed it to call tud_task(). The branch is updated.

@iabdalkader
Copy link
Contributor Author

I think it's good, you should send a PR, at least it's working now.

@robert-hh
Copy link
Contributor

Thanks for testing and helping.

@OKPersson
Copy link

Just a quick question, when you flashed the Nano 33 BLE SENSE, did you use BOSSA? I'm following the guide on the micropython site and it only gives me the error SAM-BA operation failed.

I'm sorry if this is irrelevant, might be a hardware bug or something, but the firmware should be updated to allow flashing python, I managed to get the openMV port working, but without the ability to save the python scripts to device.

@robert-hh
Copy link
Contributor

I used with a Linux machine bossac, just the command given in the update documentation. But I had to install the new bootloader first, just as documented.
See https://micropython.org/download/arduino_nano_33_ble_sense/

@OKPersson
Copy link
OKPersson commented Jul 19, 2022 •
edited
Loading

Thanks for the quick reply,

Hmm, I reflashed the new bootloader via the Nano33_updateBLandSoftDevice example, but am still getting the error after running this command.

`bossac -e -w --offset=0x16000 --port=ttyACM0 -i -d -U -R arduino_nano_33_ble_sense-20220718-unstable-v1.19.1-169-g1d23c01dd.bin
Set binary mode
version()=Arduino Bootloader (SAM-BA extended) 2.0 [Arduino:IKXYZ]
Connected at 921600 baud

SAM-BA operation failed`

Feels like I'm doing something wrong, or that my nano is faulty somehow.

Bossa is on a raspberry pi, arduino ide is on a mac.

@robert-hh
Copy link
Contributor

Did you set the board to bootloader mode by pushing reset twice? The yellow led next to the USB board will pulse.

@OKPersson
Copy link
OKPersson commented Jul 19, 2022 •
edited
Loading

yes, otherwise it will say that there is no device at that port, it's really odd. must be something wrong with my device.
It shows up in lsusb. I mean it still works to flash via arduino, but I don't get why it's not working otherwise.

As I am getting the same error via 4 different computers there almost has to be something wrong with the nano, or the bootloader version that I have flashed, tried flashing using bossa via 2 raspberry pi models, one windows 10 computer and a macbook. Always the same error SAM-BA operation failed, and I have tried using the gui version of bossa on windows.

flashed the bootloader via arduino ide 1 and 2 from mac and windows as well.

LOL, only wanted to be able to share the same code as my new raspberry pico with micropython.

@iabdalkader
Copy link
Contributor Author

Maybe it's that particular bossac version that's the issue ? Can you post bossac -V. Also you can find pre-built binaries that are known to work, here:

https://github.com/openmv/qt-creator/tree/01e2cbd232bc764ccb179382bdc5fc1fcd121ce0/share/qtcreator/bossac

@OKPersson
Copy link

Bossac -V doesn't work, however seems to be version 1.9.1-1 in the debian/raspbian repos. I'll try your link thanks.

@OKPersson
Copy link

That worked!, Big thanks man, you made my day haha.

@robert-hh
Copy link
Contributor

Right. I was lazy and use the pre-built version as well. Thanks for providing it @iabdalkader.

@iabdalkader
Copy link
Contributor Author

Updated docs here: #8930
with links to the binaries.

@OKPersson
Copy link

So another question, is there a quick way to erase the saved files from the arduino? I saved a main.py file to the device, which works great, a bit too great, now I am locked out.

reflashing the bootloader and softdevice and erasing via bossac doesn't seem to work, or it works until i flash micropython again.

@iabdalkader
Copy link
Contributor Author

It should be possible to upload a sketch from Arduino IDE, even if the board is running micropython.

@OKPersson
Copy link
OKPersson commented Jul 19, 2022 •
edited
Loading

Yes,

I saved a python blink example file into the arduino via micropython, which is autorunning at startup (main.py). So I tried to flash an arduino blink example to "clean" the flash, this works. I then flashed the softdevice again, and used bossac to flash micropython once again as well, the blink python example persists.

I have also tried running bossac with the -e (erase option) -u (unlock) and -a (arduino-erase option), still the python script persists.

This is a bit confusing haha, not the expected behaviour at all.

@iabdalkader
Copy link
Contributor Author

If you can find out which sector is used for filesystem and erase it, that should do it, or you could just simply recreate the filesystem in boot.py. Note you could easily brick this board in the process.

@robert-hh
Copy link
Contributor

If you get a REPL prompt, you can delete main.py:

import os.remove("main.py")

Or you recreate the file system with:

import _mkfs

@OKPersson
Copy link

That's the issue, it doens't appear in /dev/usbmodem or /dev/ttyACM0 when it's running the code. so REPL is out of the equation sadly.

@robert-hh
Copy link
Contributor

That's indeed the case. A look into the source code shows, that usb_cdc_init() is called after running main.py (line 262-267, main.c). That's a problem. If you are able to build firmware, you could move the call to usb_cdc_init() up before executing boot.py. That seems anyhow to be the better place for code exchanging data over USB.
I could build a firmware for you if you like.

@robert-hh
Copy link
Contributor

There is a firmware here with moved usb_cdc_init(). https://github.com/robert-hh/Shared-Stuff/blob/master/firmware_arduino_nano_33_ble.bin

@OKPersson
Copy link

Wow, thanks for fixing it. REPL works now.

I know just enough about programming to make stuff break, but I recon someone else would have the same problem sooner or later.

Greatly appreciated the help, now to learn some python and hopefully not break it again.

@robert-hh
Copy link
Contributor

You're welcome. Glad that it works for you. Meanwhile the fix is in the main code line, and will be part of the daily builds from tomorrow on.

@OKPersson OKPersson mentioned this pull request May 17, 2023
Closed
tannewt pushed a commit to tannewt/circuitpython that referenced this pull request Nov 13, 2023
@dhalbert
Merge pull request micropython#8577 from dhalbert/update-frozen-2023-…
146ca2a 
…11-10

update frozen libraries
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@dpgeorge dpgeorge dpgeorge left review comments

Assignees
No one assigned
Labels
port-nrf
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@iabdalkader @dpgeorge @robert-hh @OKPersson
0