jpconstantineau / Community_nRF52_Arduino

Community Add-on to the Adafruit_nRF52_Arduino Board Support Package
Other
13 stars 5 forks source link

Trying to add support for Makerdiary nRF52840 MDK Dongle #21

Open Brezensalzer opened 2 years ago

Brezensalzer commented 2 years ago

Hi, as described in this issue, I'm trying to add a new board variant (Makerdiary nRF52840 MDK Dongle) - now in the community repo. But I'm getting exactly the same error:

Global variables use 12100 bytes (5%) of dynamic memory, leaving 225468 bytes for local variables. Maximum is 237568 bytes.
Upgrading target on /dev/ttyACM0 with DFU package /tmp/arduino_build_123198/serialOut.ino.zip. Flow control is disabled, Single bank, Touch disabled

Failed to upgrade target. Error is: read failed: device reports readiness to read but returned no data (device disconnected or multiple access on port?)
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/serial/serialposix.py", line 500, in read
    raise SerialException(
serial.serialutil.SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/stl/.local/lib/python3.8/site-packages/nordicsemi/__main__.py", line 296, in serial
    dfu.dfu_send_images()
  File "/home/stl/.local/lib/python3.8/site-packages/nordicsemi/dfu/dfu.py", line 235, in dfu_send_images
    self._dfu_send_image(HexType.APPLICATION, self.manifest.application)
  File "/home/stl/.local/lib/python3.8/site-packages/nordicsemi/dfu/dfu.py", line 203, in _dfu_send_image
    self.dfu_transport.send_init_packet(init_packet)
  File "/home/stl/.local/lib/python3.8/site-packages/nordicsemi/dfu/dfu_transport_serial.py", line 155, in send_init_packet
    self.send_packet(packet)
  File "/home/stl/.local/lib/python3.8/site-packages/nordicsemi/dfu/dfu_transport_serial.py", line 243, in send_packet
    ack = self.get_ack_nr()
  File "/home/stl/.local/lib/python3.8/site-packages/nordicsemi/dfu/dfu_transport_serial.py", line 264, in get_ack_nr
    temp = [x for x in self.serial_port.read(6)]
  File "/usr/lib/python3/dist-packages/serial/serialposix.py", line 509, in read
    raise SerialException('read failed: {}'.format(e))
serial.serialutil.SerialException: read failed: device reports readiness to read but returned no data (device disconnected or multiple access on port?)

Possible causes:
- Selected Bootloader version does not match the one on Bluefruit device.
    Please upgrade the Bootloader or select correct version in Tools->Bootloader.
- Baud rate must be 115200, Flow control must be off.
- Target is not in DFU mode. Ground DFU pin and RESET and release both to enter DFU mode.

I have tried the bootloader in the versions 0.6.2 and 0.4.1 - same error.

I have no idea what's going wrong, so I would be glad for every hint. Thank You

jpconstantineau commented 2 years ago

Couple of things to try: 1- use the latest bootloader. This will ensure soft device compatibility. 2- did you validate that uf2 drag/drop was working properly by trying to install circuit python?

If the two options above work properly, we can check building a uf2 from Arduino code and see if that works.

If the above doesn't work, I suspect there is an issue with the bootloader itself. However before concluding this, let's test uf2 drag/drop first.

Brezensalzer commented 2 years ago

@jpconstantineau 1 - I have flashed mdk_nrf52840_dongle_bootloader-0.6.3_s140_6.1.1.hex on the board 2 - I've dropped adafruit-circuitpython-makerdiary_nrf52840_mdk_usb_dongle-en_GB-7.1.1.uf2 on the UF2 Flashdisk => CircuitPython works, I can edit code.py and blink the RGB LED's

Brezensalzer commented 2 years ago

@jpconstantineau

I want to give You the "big picture".

My primary goal is to make a Thread sensor node with nRF52840 hardware. This is not possible with the standard Arduino packages (eg. Adafruit) because softmodem 7.x from Nordic is needed.

There is a Arduino package with OpenThread support by soburi which works quite well. I was able to successfully build an OpenThread device with an ItsyBitsy nRF52840. I have forked soburi's repo and added support for the Makerdiary nRF52840 dongle. I also had to compile a new uf2 bootloader with softmodem 7.0.1. This combination works within the Arduino IDE, I can build and upload sketches successfully. I have written down my OpenThread experiments here.

As soburi uses the Adafruit_nRF52_Arduino repo as upstream, he asked me to integrate the board variant into the Adafruit repo. Which is not wanted and does'nt work . So I'm sitting between chairs. I want to give something back to the OpenSource community, so I really want to make this board work in the Arduino IDE within this community repo.

So the next thing I will try is to compile the bootloader again, but with softmodem 6.1.1.

jpconstantineau commented 2 years ago

This indicates that the bootloader appears to work properly...

Regarding your "big picture". I see your point. I have been looking into getting support for the nRF52833 from the source Adafruit repo but haven't got any clarity whether Adafruit would merge it in or not. The 833 requires softdevice 7.x as well.

When I looked at the 833 and circuitpython, I had issues with the circuitpython UF2 loading (or refusing to load) on the boards and this was due to problems with different softdevice versions. After manually updating the softdevice, we had to flash some special register on the chip to bypass application validation check.

To be able to bring support for the MDK, we will need to do this in 2 stages: 1 - Vanilla support with the 6.x Softdevice and bootloader 2 - Update SD to 7.x and update what's needed to make it work.

So that you know, I keep a separate repository that's in sync with the Adafruit nRF52 Arduino package and is located here. I suspect we may want to work from that fork so that we are up to date.

That repo is a true fork of the Adafruit repo (this current one is disconnected and already needs updates ) and will be easier to keep in sync with the changes they are bringing in. For some background, read this

I will be updating this community repo in the near future but as there were some changes that need to be undone/validated first, it will take some time to complete, hence my recommendation to work from the repo linked above.

We can keep the discussion here for now.

Brezensalzer commented 2 years ago

I have just compiled a Bootloader from the Adafruit Bootloader repo - Version 0.6.3, Softmodem 140 6.1.1 and flashed it on the board. Then I gave your other repo a try. Same behavior and same error message. :(

jpconstantineau commented 2 years ago

At least we can "replicate" the problem with the Adafruit BSP.
Just to double-check, what's the content of the INFO_UF2.TXT file when you go in bootloader mode?

Also, have you tried flashing the bootloader from the releases folder here: https://github.com/adafruit/Adafruit_nRF52_Bootloader/releases

Brezensalzer commented 2 years ago

I have tried the officially released Adafruit bootloaders and my self built one (from Adafruit sources) in several combinations of softdevices (6.1.1, 7.0.1 and 7.2.0) and bootloaders (0.6.2, 0.6.3, build from HEAD). The INFO_UF2.TXT always corresponds to the used bootloader/softdevice. I always get the same error when uploading a sketch. Just now INFO_UF2.TXT looks like that:

UF2 Bootloader 0.6.3-48-gcc8ea2b-dirty lib/nrfx (v2.0.0) lib/tinyusb (0.12.0-145-g9775e769) lib/uf2 (remotes/origin/configupdate-9-gadbb8c7)
Model: MDK nRF52840 USB Dongle
Board-ID: nRF52840-Dongle-v1
Date: Jan 31 2022
SoftDevice: S140 7.2.0

I think I'm doing it wrong when exchanging the softdevice versions. These have different sizes and that should be found/configured somewhere in the bootloader sources...

jpconstantineau commented 2 years ago

When I did the work with CircuitPython, it was the flashing separately of the softdevice that was breaking things... See here for the bigger story.

When I used a bootloader that had the softdevice already built-in, it was all working fine with CircuitPython.

For Arduino, I wonder if the USB productID configured would have something to do.

You can try the following: 1 - flash the released PCA10056 bootloader to the device (it uses the same reset pin, I believe you will be fine) 2 - confirm that the arduino IDE will be able to send something to it (blinky being a good test) Once that is confirmed, we can check the bootloader settings and see what USB Vendor ID and ProductID and see if that matches what the boards.txt file has.

Brezensalzer commented 2 years ago

Some progress at least...

$ nrfjprog --program pca10056_bootloader-0.6.3_s140_6.1.1.hex --chiperase -f nrf52 --verify
Parsing image file.
Verifying programming.
Verified OK.
jpconstantineau commented 2 years ago

Hardware checks out... That's progress.

Compare the USB PID between the bootloader and what's in boards.txt:

https://github.com/adafruit/Adafruit_nRF52_Bootloader/blob/master/src/boards/mdk_nrf52840_dongle/board.h#L65

https://github.com/jpconstantineau/Community_nRF52_Arduino/blob/main/boards.txt#L294

The arduino IDE looks for specific PID but I am not sure if that's enforced when selecting the serial port for uploading.

Brezensalzer commented 2 years ago

I'm feeling quite stupid...

I compared the definitions in boards.txt between the pca10045 and mdk52840 line by line.

pca10056.menu.softdevice.s140v6.build.sd_fwid=0x00B6
versus
mdk52840.menu.softdevice.s140v6.build.sd_fwid=0x00CA

I think 0x00CA is left over from my experiments with softdevice 7.0.1 ... After changing it to mdk52840.menu.softdevice.s140v6.build.sd_fwid=0x00B6 the upload within the Arduino IDE works.

facepalm

jpconstantineau commented 2 years ago

Ah. The traditional hours of troubleshooting to find the checkbox that fixes everything...

For reference, where is that ID defined in the bootloader so that we can map it here correctly?

Brezensalzer commented 2 years ago

I've found this: nrf_sdm.h Looks like it is somehow calculated from the softdevice version?

History: I've started with soburis fork for S140 7.0.1 und copied sections of the boards.txt for the MDK Dongle. So I inherited the value 0x00CA when copying this over to Your fork...

Brezensalzer commented 2 years ago

How shall we proceed? The board-/pin-definitions work and I have successfully tested i2c and SPI peripherals. The changes are pushed to my fork here. You could use it for your next release/update of your community repo?

electro-logic commented 1 year ago

Any update on this?

Brezensalzer commented 1 year ago

Sorry, no. I have switched to Zephyr/nRF Connect SDK to have working OpenThread libraries. The nRF52840 MDK dongle is supported in Zephyr and I successfully built and deployed the OpenThread Examples on it.

electro-logic commented 1 year ago

I would like to use Zephyr with PlatformIO as well, do you know if there is a tested board file?

Brezensalzer commented 1 year ago

Yes, there is a board definition (device tree) for the dongle in Zephyr/nRF Connect SDK.

electro-logic commented 1 year ago

It's a pity they are not citing the nRF Connect SDK in the makerdiary website, looks very promising. I managed to setup a working blinky project for the board, but I can't find a way to flash it from VS Code or to make it visible in the "connected devices" pane. My current workflow is to convert the .hex file to .uf2 and copying it in the device disk drive. Do you know if something smarter can be done?

Brezensalzer commented 1 year ago

Hi, you can't flash these USB dongles (including the Nordic dongle!) from within VS Code as it requires a JTAG-Debugger. If you have the nRF Connect Desktop installed and you have the nordic openbootloader on the dongle, there is the "nRF Programmer" tool included which works quite well (that's what I use). If you want to stick with uf2, there is a youtube video which might be helpful: https://www.youtube.com/watch?v=CPi44L0uzmo

electro-logic commented 1 year ago

I moved to Open bootloader, but then nRF Connect bricked the device that now is stuck without a JTAG programmer. I sent the devboard back, too messy.