nRF port improvements and pca10056 support #573

arturo182 · 2018-02-02T20:10:53Z

As mentioned in #561, both Peripheral and Scanner are working

Otherwise we get the "recipe commences before first target" messsage.

It will include the mcu-specific header based on defines.

If softdevice is available and enabled the SD function will be used, otherwise use MCU registers.

jerryneedell · 2018-02-02T21:08:45Z

I downloaded and build an image fpr the pca10056 SDK - It built fine and loaded.

make BOARD=pca10056 SD=s140
make BOARD=pca10056 SD=s140 sd -- to load soft device
make BOARD=pca10056 SD=s140 flash -- to load image
I can get to the Circuitpython REPL - Woohoo! great work.

I am not able to access the file system via ampy as I can for the feather52.
Dis I miss something in the configuration?
Is there some other way to upload files or is only the REPL available now?

arturo182 · 2018-02-02T21:34:23Z

I am fairly new to circuitpython so I wasn't aware of ampy, looks super useful, I was wondering how does one upload files to the flash fs :D

As you can guess from this, I have not tested the flashfs, I needed it in the linker scripts or otherwise I got warnings from these lines: https://github.com/adafruit/circuitpython/blob/master/ports/nrf/boards/common.ld#L2

If you want me to, I can look into fixing the issues with ampy before this is merged, I think it will be a good way to learn some more about the inner workings of the code :)

jerryneedell · 2018-02-02T21:40:49Z

So to test things like BLE scanning do you just enter the commands into he REPL manually or put the script in "freeze" then rebuild?? Just curious how you are using it.

I was able to manually execute a ble scan, but it's pretty painful ;-)

I'm OK with merging it as is and getting ampy working later but I'll leave that up to you and others.

jerryneedell · 2018-02-02T21:47:13Z

I also verified that I can still build and load the feather52 and use ampy to load files to its FS. So no harm done!!

arturo182 · 2018-02-02T22:02:35Z

I just enter REPL and type the code manually, indeed painful, so we need to get ampy working!

Good that the other boards are not broken, but still would be nice to get it working on the pca10056, just to save ourselves some sanity.

tannewt · 2018-02-02T22:52:45Z

I'm ok merging this with ampy not working as long as the other boards are fine. I'll let @microbuilder do the review.

arturo182 · 2018-02-03T01:02:12Z

After spending a few hours trying to see what was causing the issues, I'm still not entirely sure, it does seem like we are getting wrong data on UART, ampy was sending

            try:
                import os
            except ImportError:
                import uos as os
            print(os.listdir('{0}'))

But in the uart fifo we got:

Breakpoint 13, mp_parse (lex=0x20004b40 <heap+1692>, input_kind=MP_PARSE_FILE_INPUT) at ../../py/parse.c:1077
1077	        mp_obj_exception_add_traceback(exc, lex->source_name, lex->tok_line, MP_QSTR_NULL);
(gdb) p *_ff_uart
$47 = {
  buffer = 0x20014c80 <_ff_uart_buffer> "\r\003\003\r\001\004\003\003USBS *except ImportError:\n    import uos as os\npriUSBS *\004", 
  depth = 128, 
  item_size = 1, 
  count = 0, 
  wr_idx = 65, 
  rd_idx = 65, 
  overwritable = true, 
  mutex = UARTE0_UART0_IRQn
}

(The really strange part is the "USBS", where the heck does that come from...)
I will try verifying that the data received on UART is what ampy is actually sending (can flash the usb uart example, it echoes all UART transfers to the nrf52840 usb uart.

tannewt · 2018-02-03T01:11:25Z

@arturo182 I've seen USBS in USB mass storage packets. What USB descriptor are you using?

arturo182 · 2018-02-03T10:08:33Z

I see, that would point to the ATSAM chip used for the debug interface, I will try to connect a external USB to uart board and verify there.

There's also this thread on Nordic's forums: https://devzone.nordicsemi.com/f/nordic-q-a/16721/pca10040-uart-problem

I am running Linux Mint which is based on Ubuntu so that's why I might be getting similar problems, I tried another USB port and disabling auto-mount like the thread suggests but that didn't help.

arturo182 · 2018-02-03T11:11:23Z

Yes, ampy works with external USB to UART board, so it seems to be something related to the debug interface chip on the DK.

jerryneedell · 2018-02-03T12:38:41Z

How did you connect the external USB to UART board? I'm still finding my way around this SDK board.

BTW - I tried adding the ubluepy_eddystone.py and ble_scan.py (from feather52 examples) files to freeze and they do run on the pca10056.

arturo182 · 2018-02-03T12:44:14Z

The board has all the useful functions written on the back silk. Connect RX to 0.08 and TX to 0.06 and problem solved.

jerryneedell · 2018-02-03T12:46:13Z

;-) amazing what you find when you turn the board over. Thanks.

jerryneedell · 2018-02-03T13:13:03Z

Nice! - ampy is working via the USB/UART cable! I was able to put a few files onto the board and execute them!
Thanks!

jerryneedell · 2018-02-03T13:23:34Z

just a heads up - Ive have had this happen twice now:
when trying to load a file via ampy, sometimes it fails and files that were on the FS disappear..

lib
boot_out.txt
ubluepy_scan.py

jerryneedell@Ubuntu-Macmini:~/projects/feather52/examples$ ampy -d  1.5  -p /dev/ttyUSB0 put i2c_scan.py 
Traceback (most recent call last):
  File "/usr/local/bin/ampy", line 9, in <module>
    load_entry_point('adafruit-ampy==1.0.3', 'console_scripts', 'ampy')()
  File "/usr/local/lib/python3.5/dist-packages/click-6.7-py3.5.egg/click/core.py", line 722, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/lib/python3.5/dist-packages/click-6.7-py3.5.egg/click/core.py", line 697, in main
    rv = self.invoke(ctx)
  File "/usr/local/lib/python3.5/dist-packages/click-6.7-py3.5.egg/click/core.py", line 1066, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/lib/python3.5/dist-packages/click-6.7-py3.5.egg/click/core.py", line 895, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/lib/python3.5/dist-packages/click-6.7-py3.5.egg/click/core.py", line 535, in invoke
    return callback(*args, **kwargs)
  File "/usr/local/lib/python3.5/dist-packages/adafruit_ampy-1.0.3-py3.5.egg/ampy/cli.py", line 213, in put
  File "/usr/local/lib/python3.5/dist-packages/adafruit_ampy-1.0.3-py3.5.egg/ampy/files.py", line 146, in put
  File "/usr/local/lib/python3.5/dist-packages/adafruit_ampy-1.0.3-py3.5.egg/ampy/pyboard.py", line 263, in exec_
  File "/usr/local/lib/python3.5/dist-packages/adafruit_ampy-1.0.3-py3.5.egg/ampy/pyboard.py", line 255, in exec_raw
  File "/usr/local/lib/python3.5/dist-packages/adafruit_ampy-1.0.3-py3.5.egg/ampy/pyboard.py", line 225, in follow
ampy.pyboard.PyboardError: timeout waiting for second EOF reception
jerryneedell@Ubuntu-Macmini:~/projects/feather52/examples$ ampy -d  1.5  -p /dev/ttyUSB0 ls
lib
boot_out.txt
jerryneedell@Ubuntu-Macmini:~/projects/feather52/examples$

microbuilder

I'll need to make a new version of the serial bootloader to test on the PCA10056 with S140, but other than some minor changes to make it easier to use the bootloader, this looks good to me as a starting point. Perhaps @tannewt has some further feedback, though?

microbuilder · 2018-02-05T12:43:16Z

ports/nrf/boards/pca10056/mpconfigboard.h

Should this be larger? The linker script has _minimum_heap_size = 128K;, and there is plenty of free SRAM on this SoC for the heap.

How much do you recommend?

microbuilder · 2018-02-05T12:45:59Z

ports/nrf/boards/pca10056/mpconfigboard_s140.mk

A custom linker script would perhaps be better here, following the feather52 example, since we will need to use a modified version of the serial bootloader in addition to the J-Link. I guess we don't technically need the serial bootloader on the PCA10056 since it has an on board J-Link, but we can still test the serial bootloader as an option on this board until commercial modules are available with the final silicon.

Not sure how to proceed, should I leave as is until a new bootloader is available?

Don't worry about it ... I'll put the new linker script in myself when I generate the custom bootloader, since I'm not sure of the exact sizes right now anyway. I've only built it against s132.

microbuilder · 2018-02-05T12:47:27Z

ports/nrf/boards/pca10056/mpconfigboard_s140.mk

Adding a ?= like this: SOFTDEV_VERSION ?= 2.0.1 will make it easier to override this from the command line.

jerryneedell · 2018-02-05T13:38:11Z

While you are modifying the linker files, would it be worth making the File System larger for the PCA10056? I tried increasing it from 0x19000 to 0x40000 ( 100K -> 256K ) and it seems to be working fine.

arturo182 · 2018-02-05T14:36:12Z

@jerryneedell can do!

microbuilder · 2018-02-05T17:59:28Z

Testing this on the actual HW, and OUCH ... the core firmware file is HUGE!

Running make V=1 board=pca10056 SD=s140 I get:

LINK build-pca10056-s140/firmware.elf
   text	   data	    bss	    dec	    hex	filename
 185192	   1188	 239732	 426112	  68080	build-pca10056-s140/firmware.elf
arm-none-eabi-objcopy -O binary build-pca10056-s140/firmware.elf build-pca10056-s140/firmware.bin
arm-none-eabi-objcopy -O ihex build-pca10056-s140/firmware.elf build-pca10056-s140/firmware.hex

Running a similar command on the feather52 target with S132v2.0.0 (make V=1, using default settings) I get less than half that size:

LINK build-feather52/firmware.elf
   text	   data	    bss	    dec	    hex	filename
 168928	   1188	  36788	 206904	  32838	build-feather52/firmware.elf
arm-none-eabi-objcopy -O binary build-feather52/firmware.elf build-feather52/firmware.bin
arm-none-eabi-objcopy -O ihex build-feather52/firmware.elf build-feather52/firmware.hex

I'll have to look at what's enabled and what isn't to compare, but that's a MASSIVE difference and doesn't take into account the internal file system, SoftDevice or bootloader. Unless the SD is included in that binary? I'll dig into what those numbers mean now, but ouch. :)

UPDATE: Sorry, the difference is purely in the .bss section (uninitialized data), so it doesn't affect flash space. The .text section is actually smaller, which is what's important here.

microbuilder · 2018-02-05T18:43:34Z

The --format=SysV option of GNU size gives a more useful breakdown:

$ arm-none-eabi-size --format=SysV build-pca10056-s140/firmware.elf 
build-pca10056-s140/firmware.elf  :
section             size        addr
.isr_vector          248      151552
.text             184952      155648
.data               1188   536887296
.bss               67700   536888484
.heap             131072   536956184
.stack             40960   537087256
.ARM.attributes       57           0
.comment             110           0
.debug_frame        2476           0
Total             428763

jerryneedell · 2018-02-05T18:52:09Z

For the nrf52840 the .ld files have the _minimum_heap_size set to 128K while the feather52 has this set to 0. That is adding a big area to the .bss.

$ arm-none-eabi-size --format=SysV build-feather52-s132/firmware.elf
build-feather52-s132/firmware.elf  :
section             size        addr
.isr_vector          216      114688
.text             182624      118784
.data               1192   536883200
.bss               34916   536884392
.heap                  0   536919308
.stack              2048   536919308
.ARM.attributes       57           0
.comment             126           0
.debug_frame        2788           0
Total             223967

microbuilder · 2018-02-05T20:14:47Z

@jerryneedell Yeah, the heap and memory is managed differently, I noticed that after the fact.

@arturo182 If you want to push the minor changes suggested earlier, I'll merge this in, and will work on getting bootloader support in a new PR since that will require some changes on my end? Basic REPL works fine, and we can make improvements from there to make sure internal file system support is stable, etc.

arturo182 · 2018-02-05T20:16:17Z

@microbuilder I pushed the changes in the commit just before your comment.

jerryneedell · 2018-02-05T21:19:13Z

FWIW - I downloaded #573 and made build for the feather52 and PCA10056 - both appear to be functional. Tested SPI on both builds (mounted SD Card). quick I2C test on PCA10056 (MCP9808 temperature sensor OK) - executed ble_scan.py example on PC10056.
Here are the build stats for the PCA10056 - removing heap helped!

$ arm-none-eabi-size --format=SysV build-pca10056-s140/firmware.elf
build-pca10056-s140/firmware.elf  :
section             size        addr
.isr_vector          248      151552
.text             182840      155648
.data               1192   536887296
.bss              133232   536888488
.heap                  0   537021720
.stack             40960   537021720
.ARM.attributes       57           0
.comment             126           0
.debug_frame        2788           0
Total             361443

microbuilder

This seems good for a first pass at nRF52840 support on the PCA10056. I'm OK with merging this in, and we can get to work on a serial bootloader and USB support, but this gets the ball rolling. Thanks for the hard work here!

arturo182 added 6 commits February 2, 2018 20:31

nrf: Fix errorneous indent

a776c2a

Otherwise we get the "recipe commences before first target" messsage.

nrf: Use the right SPI registers on nRF52840

d0b451b

nrf: Use more generic header

616cbc6

It will include the mcu-specific header based on defines.

nrf: Add flash section for fatfs for no SD pca10056

fed9087

nrf: Add SD 6.0.0-6.alpha to the download script

c6a542d

nrf: Implement MCU temperature reading

6731b47

If softdevice is available and enabled the SD function will be used, otherwise use MCU registers.

tannewt requested a review from microbuilder February 2, 2018 22:52

arturo182 mentioned this pull request Feb 3, 2018

nRF Port: Get Remaining Shared Modules Working #526

Closed

8 tasks

microbuilder reviewed Feb 5, 2018

View reviewed changes

nrf: Get the port working on pca10056 (nRF52840)

76f5c01

arturo182 force-pushed the master branch from aaa8c23 to 76f5c01 Compare February 5, 2018 19:41

microbuilder approved these changes Feb 6, 2018

View reviewed changes

microbuilder merged commit c433a82 into adafruit:master Feb 6, 2018

This was referenced Feb 6, 2018

nrf52840: Add serial bootloader #585

Closed

nRF52840 port #561

Closed

nRF port improvements and pca10056 support #573

nRF port improvements and pca10056 support #573

Uh oh!

Conversation

arturo182 commented Feb 2, 2018

Uh oh!

jerryneedell commented Feb 2, 2018

Uh oh!

arturo182 commented Feb 2, 2018

Uh oh!

jerryneedell commented Feb 2, 2018

Uh oh!

jerryneedell commented Feb 2, 2018

Uh oh!

arturo182 commented Feb 2, 2018

Uh oh!

tannewt commented Feb 2, 2018

Uh oh!

arturo182 commented Feb 3, 2018

Uh oh!

tannewt commented Feb 3, 2018

Uh oh!

arturo182 commented Feb 3, 2018

Uh oh!

arturo182 commented Feb 3, 2018

Uh oh!

jerryneedell commented Feb 3, 2018

Uh oh!

arturo182 commented Feb 3, 2018

Uh oh!

jerryneedell commented Feb 3, 2018

Uh oh!

jerryneedell commented Feb 3, 2018

Uh oh!

jerryneedell commented Feb 3, 2018

Uh oh!

microbuilder left a comment

Choose a reason for hiding this comment

Uh oh!

microbuilder Feb 5, 2018

Choose a reason for hiding this comment

Uh oh!

arturo182 Feb 5, 2018

Choose a reason for hiding this comment

Uh oh!

microbuilder Feb 5, 2018

Choose a reason for hiding this comment

Uh oh!

arturo182 Feb 5, 2018

Choose a reason for hiding this comment

Uh oh!

microbuilder Feb 5, 2018

Choose a reason for hiding this comment

Uh oh!

microbuilder Feb 5, 2018

Choose a reason for hiding this comment

Uh oh!

arturo182 Feb 5, 2018

Choose a reason for hiding this comment

Uh oh!

jerryneedell commented Feb 5, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

arturo182 commented Feb 5, 2018

Uh oh!

microbuilder commented Feb 5, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

microbuilder commented Feb 5, 2018

Uh oh!

jerryneedell commented Feb 5, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

microbuilder commented Feb 5, 2018

Uh oh!

arturo182 commented Feb 5, 2018

Uh oh!

jerryneedell commented Feb 5, 2018

Uh oh!

microbuilder left a comment

jerryneedell commented Feb 5, 2018 •

edited

Loading

microbuilder commented Feb 5, 2018 •

edited

Loading

jerryneedell commented Feb 5, 2018 •

edited

Loading