Trying to build for NRF52832 SDK11

I'm putting Espruino on an older sports band which uses SDK11. I have a board file which indicates "NRF_SDK11=1" and have done a scripts/provision.sh with the board. The build stops immediately saying No rule to make target 'targetslib/nrf5x_11/components/toolchain/gcc/gcc_startup_nrf52.o', needed by 'bin/espruino_2v18.69_ID130.elf'. Stop.
Sure enough, there is no targetlibs/nrf5x_11 directory; there is nrf5x, nrf5x_12, nrf5x_14. Is this the Nordic SDK11? Do I need to install that?

take targetlibs_nrf5x_11.tgz from https://github.com/fanoush/ds-d6/tree/master/espruino and extract in espruino root folder via tar zxvf filename

Thanks @fanoush!

If you want we can set it up like we do for the other SDKs (apart from 12) so we have a zip on EspruinBuildTools that the provision script pulls in?

Well, it is pretty old file, let's wait for @yngv126399 to check whether it still works. I haven't used it for quite some time too. If it still works it can be zipped and put there. However it is patched a bit already.

Just tried and there is some minor breakage but with some tweaking it works.

One issue is that nrf_gpio_pin_port_decode is mostly ifdef-ed for NRF_SD_BLE_API_VERSION>5 https://github.com/search?q=repo%3Aespruino/Espruino%20nrf_gpio_pin_port_decode&type=code
except for one place
https://github.com/espruino/Espruino/blob/e5617094e3480ada254d7771ad70f73b923a951a/targets/nrf5x/jshardware.c#L1680
Since this method appears to be defined in Espruino version of SDK12, it works. So not sure if the ifdef could be removed elsewhere or added in this one new place.

Adding I2C slave support broke SDK11 too. SDK11 version of drivers throws error when i2c slave is not enabled
targetlibs/nrf5x_11/components/drivers_nrf/twis_slave/nrf_drv_twis.c:19:2: error: # error "TWIS driver included but none of TWIS devices is activated in the configuration file"
Can be patched out in the driver file by changing #error into #warning and adding #else/#endif around all the code definitions that follow

Also the change of including i2c/spi/serial code only if their count in board file is >0 broke SDK11. However I wonder why it works even for other SDKs than 12 as the code handling SPI/I2C/USART _COUNT here https://github.com/espruino/Espruino/blob/e5617094e3480ada254d7771ad70f73b923a951a/targets/nrf5x/app_config.h#L126 is inside a big block of other definitions all used only for SDK12 https://github.com/espruino/Espruino/blob/e5617094e3480ada254d7771ad70f73b923a951a/targets/nrf5x/app_config.h#L65 (??) so for 532840/SDK15 this is not evaluated(?)

Quick workaround for me was adding DEFINES+=-DTWI_ENABLED=1' to board file but maybe those ifdef SPI/I2C/USART _COUNT>0 parts can be moved out of SDK12=only ifdef. I think I tried to configure out some of those on some 52840/SDK15 watches, not sure how it worked, will check.

Thanks for checking on that. I did untar the file and I'm getting the same build errors. If I get a chance tonight I'll see if #ifdef-ing areas appropriately gets a working build (I'll try it out on a 52832 DK) and report back

Thanks! I just pushed some changes based on what you'd said above @fanoush which should fix things.

Maybe for SDK15 we don't really use SPI/I2C from code (since it's just for Bangle.js 2) so we never noticed that they weren't getting set correctly? I've just moved those definitions now

which should fix things.

Thanks! It did fix all errors and now it builds fine for me out of box.
I made a build for E104-BT5032A board (as it has SWD available to recover) with SDK11 softdevice/bootloader and flashed it over DFU and it works :-)
I can connect WebIDE to it over bluetooth and basic stuff works, it is running S132 2.0.1 (= ID 0x88)

>process.env
={
  VERSION: "2v18.566",
  GIT_COMMIT: "770e47fd9",
  BOARD: "E104BT5032A",
  RAM: 65536, FLASH: 524288, STORAGE: 81920,
  SERIAL: "cd728763-9f160e6b",
  CONSOLE: "Bluetooth",
  MODULES: "Flash,Storage,heatshrink",
  EXPTR: 318612 }
>peek16(0x300c).toString(16)
="88"

@yngv126399 looks like it is moderately safe to try some watch :-)

If you want we can set it up like we do for the other SDKs (apart from 12) so we have a zip on EspruinBuildTools that the provision script pulls in?

In current state the file works as is so I could possibly make it into a zip an make a PR.

However there is no bootloader source to easily integrate and compile so only DFU zips would be buildable. However I just tried and the adafruit-nrfutilpip package conflicts with nrfutil. When installed it basically overwrites newer nrfutil with older nordic libraries so both commands run old legacy version, how to solve that? Sometime ago I solved it by installing nrfutil in python2 and adafruit-nrfutil in python3 but nowadays python2 is really old so not sure how provision script could properly install both without any breakage.

I could possibly make it into a zip an make a PR.

That would be great! Ideally we'd do it like we do for SDK15 with Nordic SDK files and a patchset, but SDK11 is niche enough I don't think that really matters.

adafruit-nrfutil pip package conflicts with nrfutil

Maybe just use adafruit-nrfutil from the Makefile, and leave how to install it up to the person building?

Probably having only DFU zips for most people isn't a big deal since that's why you'd use SDK11 surely? If you could write via SWD you'd just use a newer SDK?

Maybe just use adafruit-nrfutil from the Makefile, and leave how to install it up to the person building?

Well, the point of scripts/provision.sh BOARDNAME is to get everything prepared, so next step is make that works. It installs nrfutil for other SDKs too. So in that sense it would do only half of the job for SDK11 and won't allow e.g. automated building from github pipelines. So adding symmetrical pip install adafruit-nrfutil would make better sense, otherwise adding automated SDK11 download is not that much useful.

Well, except that it would break your existin nrfutil install when you are building locally. So my thinking/question was if both versions of the nrfutil could be installed in a better way.

Maybe by using venv https://docs.python.org/3/library/venv.html into some espruino folder? like arm gcc compiler or esp32 sdk or other parts downloaded by provision script.

Yes, having some way to install adafruit-nrfutil in a subfolder rather than globally definitely seems like the way forward.

For stuff like ESP32 we do that and set up the path temporarily - then if someone wants to have it permanent without running the provision script at startup they can always copy the displayed paths into .bashrc/similar.