search

Koenkk / Z-Stack-firmware

Compilation instructions and hex files for Z-Stack firmwares
MIT License
2.38k stars 647 forks source link

CI: Add automated container build for Z-Stack 3.x.0 #507

Open oliv3r opened 3 months ago

oliv3r commented 3 months ago

This commit adds a Container which holds the CCS and SDK so they can be used to build the various firmwares.

The pipeline can be later expanded to also actually build the firmware(s).

oliv3r commented 3 months ago

I'm debating as to keep this MR as is (and put the firmware building in a subsequent MR) or add that to this MR. The reason being, that I'm stuck at the moment on the firmware.patch file.

So first off all, I assume the patch (other then adding various bits and pieces) toggles between coordinator and router mode amongst things. I wonder if it was not possible to split up the patches into more specific patches, and maybe apply them all everywhere, (except the configuration changes).

Anyway, where I'm stuck with is applying the patch. The code changes apply fine, I did clean up some whitespace issues in #506 that make things just a bit cleaner to apply.

But next is the various znp.syscfg changes, which none apply at all. Interestingly, when looking at the files, there seems to be no relation to the patch and the actual content. This could be potentially on how the project gets imported?

I've imported them as such:

# eclipse -noSplash -data "${HOME}/workspace" -application com.ti.ccstudio.apps.projectImport -ccs.location "${HOME}/examples/rtos/CC26X2R1_LAUNCHXL/zstack/znp/tirtos7/ticlang/znp_CC26X2R1_LAUNCHXL_tirtos7_ticlang.projectspec"
# eclipse -noSplash -data "${HOME}/workspace" -application com.ti.ccstudio.apps.projectImport -ccs.location "${HOME}/examples/rtos/CC1352P_2_LAUNCHXL/zstack/znp/tirtos7/ticlang/znp_CC1352P_2_LAUNCHXL_tirtos7_ticlang.projectspec"
# eclipse -noSplash -data "${HOME}/workspace" -application com.ti.ccstudio.apps.projectImport -ccs.location "${HOME}/examples/rtos/LP_CC2652RB/zstack/znp/tirtos7/ticlang/znp_LP_CC2652RB_tirtos7_ticlang.projectspec"
# eclipse -noSplash -data "${HOME}/workspace" -application com.ti.ccstudio.apps.projectImport -ccs.location "${HOME}/examples/rtos/LP_CC1352P7_4/zstack/znp/tirtos7/ticlang/znp_LP_CC1352P7_4_tirtos7_ticlang.projectspec"
# eclipse -noSplash -data "${HOME}/workspace" -application com.ti.ccstudio.apps.projectImport -ccs.location "${HOME}/examples/rtos/LP_CC2652R7/zstack/znp/tirtos7/ticlang/znp_LP_CC2652R7_tirtos7_ticlang.projectspec"

This works, but the configured file is completely different then what is apparently expected. For example looking at workspace/znp_CC1352P_2_LAUNCHXL_tirtos7_ticlang/znp.syscfg

The file I'm having in the container is exactly the same as can be seen online on the Texas Instruments Z-Stack examples github. I first thought this was somehow related to the Project Import, but since the SDK CLI workspace import is completly identical to the git file above, I doubt there's any relation there.

Maybe the instructions are old, and the patch was done against an older import?

For a moment I also thought that [https://github.com/TexasInstruments/simplelink-zstack-examples/blob/lpf2-7.10.02.23-zstack/examples/rtos/CC1352P_2_LAUNCHXL/zstack/znp/tirtos7/znp.syscfg#L32](// @cliArgs --board /ti/boards/CC1352P_2_LAUNCHXL --rtos tirtos7) had any relation to my import, but alas, this is also identical.

So @Koenkk how did you generate your firmware patch with relation to the znp.syscfg and would it still behave/work exactly the same if you created a new import from scratch? Maybe your files where never updated through various CCS/SDK updates?

I did figure to try to manually apply the changes anyway, but some settings do not even exist (The CCFG stuff for example) so figured I give up, having spend all weekend on this and figure out what's going on.

P.S. Obviously, I couldn't do the 'edit to 1000 and back' hack, as there's no GUI involved. P.P.S. I initially started off with SDK 7.41.00.17 and CCS 12.7.1 which both worked fine, up until the patch application. This is when I started to roll back things to the exact versions mentioned in the README. The version can easily be supplied as docker build args, or best updated in the file (on releases).

Koenkk commented 3 months ago

It's because step 6 from https://github.com/Koenkk/Z-Stack-firmware/blob/master/coordinator/Z-Stack_3.x.0/COMPILE.md is missing.

Could you also add some docs on how to use this?

oliv3r commented 2 months ago

Right! Ok so my intend was to add a full-featured pipeline that builds part 'as documentation' but let me write up the 'manual' compiling step first. Thanks @Koenkk

Anyway, I am wondering on how to do 'step 6'. I'm importing the project as described above with

#eclipse -noSplash -data "${HOME}/workspace" -application com.ti.ccstudio.apps.projectImport -ccs.location "${HOME}/examples/rtos/CC1352P_2_LAUNCHXL/zstack/znp/tirtos7/ticlang/znp_CC1352P_2_LAUNCHXL_tirtos7_ticlang.projectspec"

So changing the file is just editing the value, which won't generate any code, but apparently changing the value causes eclipse to do magic. This is also not obvious and clear in the instruction of step 6 (though to be fair, feels obvious as that is what these tools tend to do).

I'll see if there's a CLI option to modify the znp config to trigger the same behavior, otherwise, I wonder if it is not far more sensible to just include these changes in the patch ...

Also, I'm very curious if we can make this work for all flavors from the root, or if we would have to put it in the subdirectories. I admit, I didn't look at the other stuff, thinking it would figure itself out, but I also saw just now that the 3.0.x stack is based on IAR and a different Z-stack, so this approach may not even be possible there ... The only thing I'm hopeing for, if we can combine the coordinator and router patches, so that it only ends up being a compile flag.

oliv3r commented 2 months ago

I've pushed with just some documenation changed added, which are not correct yet :) (I'll split-up the patches first, to make things logical, and update the documentation to match suit).

But I need to first figure out how to get this 100 -> 1000 -> 100 trick to work with the CLI, and otherwise put that in the patch as well or something. Will see. Just wanted to add the documentation first so it becomes clear what is happening.

Koenkk commented 2 months ago

@oliv3r I'm wondering if you can run the the sysconfig from the container somehow, I think a simple save action should be enough.

oliv3r commented 2 months ago

Sysconf is installed, so just gotta gigure out the magic ;)

oliv3r commented 2 months ago

@Koenkk might be harder then expected. I tried ...

I tried both importing the project from the examples, and even creating a new project, in both cases as expected, the znp.syscfg are nearly identical. Not surprising really.

So then I figured, well lets try to modify this project znp.sysconfig file, which I did using

sysconfig_cli.sh --output /build/workspace/znp_CC1352P_2_LAUNCHXL_tirtos7_ticlang/ --board '/ti/boards/CC1352P_2_LAUNCHXL' --product '/build/simplelink_cc13xx_cc26xx_sdk_7_10_00_98/.metadata/product.json' --rtos 'tirtos7' /build/simplelink_cc13xx_cc26xx_sdk/source/ti/zstack/sysconfig/znp.syscfg

Sadly, it generated the exact same file.

So for now I'm just going to add the file to the repo, because if I look at the eclipse 'generated' file, it just overwrites whatever was there anyway. Completely generates it 'from scratch'. And yes, it most likely uses sysconfig; but I have no idea how. The arguments to sysconfig_cli.sh are obscure. Having said that, reading their documentation we see that you have to use the sysconfig tool to generate the code for IAR as well. So it must be possible certainly.

Anyway, I've asked the gods that are TI; https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1397346/cc2652p-using-sysconfig-from-the-cli-to-generate-znp-sysfg

oliv3r commented 2 months ago

@Koenkk I hope you have a few moments to help explain something to me.

I was able to build functional firmwares, but as I was cleaning the patches up a little, I ran into an error situation with regards to the ti_devices_config.c, ti_radio_config.c, ti_radio_config.h and ti_drivers_config.h. From what I can see, those are actually generated by sysconfig.

Generating Code (znp.syscfg)...
Writing /build/workspace/znp_CC1352P_2_LAUNCHXL_tirtos7_ticlang/default/syscfg/ti_zstack_config.c...
Writing /build/workspace/znp_CC1352P_2_LAUNCHXL_tirtos7_ticlang/default/syscfg/ti_zstack_config.h...
Writing /build/workspace/znp_CC1352P_2_LAUNCHXL_tirtos7_ticlang/default/syscfg/ti_devices_config.c...
Writing /build/workspace/znp_CC1352P_2_LAUNCHXL_tirtos7_ticlang/default/syscfg/ti_radio_config.c...
Writing /build/workspace/znp_CC1352P_2_LAUNCHXL_tirtos7_ticlang/default/syscfg/ti_radio_config.h...
Writing /build/workspace/znp_CC1352P_2_LAUNCHXL_tirtos7_ticlang/default/syscfg/ti_drivers_config.c...
Writing /build/workspace/znp_CC1352P_2_LAUNCHXL_tirtos7_ticlang/default/syscfg/ti_drivers_config.h...
Writing /build/workspace/znp_CC1352P_2_LAUNCHXL_tirtos7_ticlang/default/syscfg/ti_utils_build_linker.cmd.genlibs...
Writing /build/workspace/znp_CC1352P_2_LAUNCHXL_tirtos7_ticlang/default/syscfg/syscfg_c.rov.xs...
Writing /build/workspace/znp_CC1352P_2_LAUNCHXL_tirtos7_ticlang/default/syscfg/ti_sysbios_config.h...
Writing /build/workspace/znp_CC1352P_2_LAUNCHXL_tirtos7_ticlang/default/syscfg/ti_sysbios_config.c...
Finished building: "../znp.syscfg"

However, in the patch, you place a copy (i diffed them to the generated ones, they are identical) in the workspace root. Why is this?

Further more, I spotted some redefinition errors in relation to these files,

In file included from syscfg/ti_drivers_config.c:18:
/build/workspace/znp_CC1352P_2_LAUNCHXL_tirtos7_ticlang/default/syscfg/ti_drivers_config.h:99:9: warning: 'CONFIG_RF_24GHZ' macro redefined [-Wmacro-redefined]
#define CONFIG_RF_24GHZ 28

Was this intended? Or did you just forget to #undef these?

Other then that, I am able to build firmwares now, and am about to try them on my stick, hoping it won't brick :)

Koenkk commented 2 months ago

These files should be excluded from syscfg generation (as done here). The reason for this is that we need to change some defines here (which is done here: https://github.com/Koenkk/Z-Stack-firmware/blob/579956b4e143d72c89410f1088be5edc3f72c6eb/coordinator/Z-Stack_3.x.0/firmware.patch#L492) + support TX power of 5 - 14.

oliv3r commented 2 months ago

These files should be excluded from syscfg generation (as done here). The reason for this is that we need to change some defines here (which is done here:

https://github.com/Koenkk/Z-Stack-firmware/blob/579956b4e143d72c89410f1088be5edc3f72c6eb/coordinator/Z-Stack_3.x.0/firmware.patch#L492 ) + support TX power of 5 - 14.

Not sure I follow, yes, you exclude them; but then you also add those files in a different location in firmware.patch. This for example is what I am talking about. Removing that works just fine (tm).

Anyway, I'm not finished with the cleanup; I want to split the big 'split' patch into a few logical ones; but this right now should be my current state ...

While looking into the pre-include redefinitions, I am getting now more confused about your statement :) So we let the sysconfig generate the files, but we won't use them during the build? Or should it be prevented from generating them? Currently, you have 'added' the (generated I presume) files into the root of the workspace. Was this an 'archive' instead of remove and accidentally committed? When I moved the files (as I thought they where needed) into a different location, I was getting compilation errors about those missing files. Looking at the redefinitions

In file included from syscfg/ti_drivers_config.c:18:
/build/workspace/znp_CC1352P_2_LAUNCHXL_tirtos7_ticlang/default/syscfg/ti_drivers_config.h:99:9: warning: 'CONFIG_RF_24GHZ' macro redefined [-Wmacro-redefined]
#define CONFIG_RF_24GHZ 28
        ^
/build/simplelink_cc13xx_cc26xx_sdk/source/ti/ti154stack/../../../source/ti/zstack/stack/config/preinclude.h:151:17: note: previous definition is here
        #define CONFIG_RF_24GHZ                         0x0000001c
                ^

I am more confused, because the values are identical. E.g. 28 == 0x1C. So if the configured values are the same, why redefine them at all?

+    #!ifdef LAUNCHPAD_CONFIG
+        #undef CONFIG_RF_24GHZ
+        #define CONFIG_RF_24GHZ                         0x0000006
+        #undef CONFIG_RF_HIGH_PA
+        #define CONFIG_RF_HIGH_PA                       0x0000005
+        #undef SET_CCFG_MODE_CONF_XOSC_CAPARRAY_DELTA
+        #define SET_CCFG_MODE_CONF_XOSC_CAPARRAY_DELTA  0xfa
+    #endif

would work the same, no? (Caution with those undefs, it would hide the error, but the used value is actually from the ti_drivers_config.h. Caveat emptor.

So sorry for not quite understanding what is being accomplished here ...

Update: So I spoke to soon, while I was messing with my patches, I had put those excludes into the comment section (was trying to move them out of the generated file, into the actual sources), and removing the file indeed does trigger the 'missing'.

I'll keep messing with this, but then why does it work if those (generated, but moved) files are placed into the workspace root; and why couldn't we get the sysconfig generator to produce those required files? Is there no syscfg setting we could modify to our desire?

As I'm playing around with things, it certainly looks like the there's a relation (duh)

--- syscfg/excluded/ti_devices_config.c 2024-08-08 09:23:12.589479479 +0200
+++ syscfg/ti_devices_config.c  2024-08-08 09:54:15.346282155 +0200
@@ -19,11 +19,11 @@
 // Power settings
 //#####################################

-// Do not use the DC/DC during recharge in powerdown
-#define SET_CCFG_MODE_CONF_DCDC_RECHARGE                0x1
+// Use the DC/DC during recharge in powerdown
+#define SET_CCFG_MODE_CONF_DCDC_RECHARGE                0x0

-// Do not use the DC/DC during active mode
-#define SET_CCFG_MODE_CONF_DCDC_ACTIVE                  0x1
+// Use the DC/DC during active mode
+#define SET_CCFG_MODE_CONF_DCDC_ACTIVE                  0x0

 //#####################################
@@ -55,7 +55,7 @@
 #define SET_CCFG_BL_CONFIG_BL_ENABLE                    0xC5

 // DIO number for boot loader backdoor
-#define SET_CCFG_BL_CONFIG_BL_PIN_NUMBER                0xf
+#define SET_CCFG_BL_CONFIG_BL_PIN_NUMBER                0x10

 // Active low to open boot loader backdoor
 #define SET_CCFG_BL_CONFIG_BL_LEVEL                     0x0

...
 // PARAMETER SUMMARY
 // Channel - Frequency (MHz): 2405
-// TX Power (dBm): 20
+// TX Power (dBm): 19

 // TI-RTOS RF Mode Object
 RF_Mode RF_prop_ieee154 =
@@ -161,7 +161,7 @@
 {
     // override_tx20_placeholder.json
     // TX HighPA power override
-    TX20_POWER_OVERRIDE(0x003F75F5),
+    TX20_POWER_OVERRIDE(0x003F61E2),
     // The ANADIV radio parameter based on LO divider and front end settings
     (uint32_t)0x01C20703,
     // override_tx20_settings.json

this is the diff from changing the DCDC mode from true/false and changing the boot key from 15 to 16 and zstack.rf.txPower to 19. If it's just a matter of finding the correct values for the znp.syscfg to trigger these events, that's probably more favorable then hacking it into preinclude don't you agree?

Oh, I just see that CONFIG_RF_24GHZ and CONFIG_RF_HIGH_PA are in the 'GPIO' section of ti_drivers_config.h so these are just pins? Why are they being overwritten in preinclude; in the znp.syscfg they are

RF.rfAntennaPin0.$suggestSolution            = "DIO_28";
RF.rfAntennaPin1.$suggestSolution            = "DIO_29";
RF.rfAntennaPin2.$suggestSolution            = "DIO_30";

Do pardon my ignorance :p but image

I found where this is set, and from the 'suggestSolution' this seems to be 'randomly generated' which is probably why you set it to a fixed value in your pre-include. I think the solution is simple, make it a fixed value in the znp.syscfg. So looking at the IDE, I see that there's a few pre-defined pins, which I can't choose, so I'm gonna figure out now how to add more pins to that list, so they can be properly assigned, which removes this preinclude need I hope?

(i'd assume that all of these pins need to be pre-assigned to fixed values ... randomly assigned pin values are never nice ;p)

Display1.uart.uart.$suggestSolution          = "UART0";
Display1.uart.uart.txPin.$suggestSolution    = "boosterpack.4";
Display1.uart.uart.rxPin.$suggestSolution    = "boosterpack.3";
RF.rfAntennaPin0.$suggestSolution            = "DIO_28";
RF.rfAntennaPin1.$suggestSolution            = "DIO_29";
RF.rfAntennaPin2.$suggestSolution            = "DIO_30";
Button1.button.$suggestSolution              = "boosterpack.13";
Button2.button.$suggestSolution              = "boosterpack.8";
LED1.ledPin.$suggestSolution                 = "boosterpack.39";
LED2.ledPin.$suggestSolution                 = "boosterpack.40";
NVSSPI25XDevice1.chipSelect.$suggestSolution = "boosterpack.38";
SPI1.spi.$suggestSolution                    = "SSI0";
SPI1.spi.sclkPin.$suggestSolution            = "boosterpack.7";
SPI1.spi.pociPin.$suggestSolution            = "boosterpack.14";
SPI1.spi.picoPin.$suggestSolution            = "boosterpack.15";
SPI1.spi.dmaRxChannel.$suggestSolution       = "DMA_CH3";
SPI1.spi.dmaTxChannel.$suggestSolution       = "DMA_CH4";
Timer.rtc.$suggestSolution                   = "RTC0";
Koenkk commented 2 months ago

These files are initially generated but then slightly modified (all lines which have // CUSTOM above them). E.g. the CONFIG_RF_24GHZ can be set to 0x0000006 or 0x0000001c depending on wether you compile with #define LAUNCHPAD_CONFIG 1 commented or not (in preinclude.h)

oliv3r commented 2 months ago

I got myself stuck in a little corner, no idea (yet) what went wrong, but while I can flash the firmware, using zigpy form will result in enless nothing ness. info will complain about an no network being formed yet. Having tried form once however, and trying info or form again, results in the firmware responding with zigpy_znp.exceptions.InvalidCommandResponse: Expected SRSP response SYS.OSALNVWriteExt.Rsp(Status=<Status.SUCCESS: 0>), got SYS.OSALNVWriteExt.Rsp(Status=<Status.NV_OPER_FAILED: 10>) but no idea if this is even a reasonable exected error, or just a random failure error number being translated.

So I went back to the start, and trying a different approach (with smaller reverse order) changes, so they are more easy to follow, and I can do intermediate build steps. The result will be exactly the same, just in the opposite order :p And it'll help me understand these radio configuration changes.

Sorry but bear with me :) It'll be good :p

oliv3r commented 2 months ago

@Koenkk I've pushed all my changes for now, but we'll probably want to merge them via seperate merge requests. I think upto the container stuff, we can leave here; the others are probably generic nice cleanups we can do via 2 or 2 merge requests. Also, for it to be merged in its current state, you'd need to fork the two TI repositories (SDK and examples). It's not a hard requirement, but a) i've put the submodule links already in your name :p and I think it's much easier to work with/use. Actually in the future, it would be even better if we could actually build from those sources, but I was getting errors about missing source/sdk so I didn't spend much thoughts on it. Oth I also had just started out with this journey and gave up rather quickly :p

One 'issue' I am still struggling with, is the 'others' target. After playing a bit with the docker stuff, maybe you can help out here. I copied the config of the standard LAUNCHXL and removed the RED led. This is important, as otherwise, invoking the RED led from software, would trigger the RF Switch on these 'other' devices (are we even exposing the RED led in any way? Is the software even using it at all? maybe not, and then it's not an issue ...) After that, I wanted to assign the proper GPIO's via the GUI; but no matter what I tried, the IDE won't let me do it. Fixing the values as I did now makes the IDE unhappy and likewise, building from the CLI makes everything puke.

In a previous experiment, I had found a checkbox/migration button in syscfg under 'board view', which converted the launchpad board to a generic board. This might probably the better solution of course. Converting the board works for the syscfg, which is only slightly different, however you_must_implement_rfDriverCallbackAntennaSwitching_see_generated_ti_drivers_config_c_in_debug_folder_or_sysconfig_preview undefined symbol error pops up (which is a known thing). So kind of stuck on this one. The obvious simplest thing is just to 'copy' the LP example into an 'other' example... but then, maybe this is something that the bullet needs to be bitten on and do it generic for all boards ...

diff --git a/coordinator/Z-Stack_3.x.0/znp_CC1352P_2_other.syscfg b/coordinator/Z-Stack_3.x.0/znp_CC1352P_2_other.syscfg
index 8d35d05..46edb21 100644
--- a/coordinator/Z-Stack_3.x.0/znp_CC1352P_2_other.syscfg
+++ b/coordinator/Z-Stack_3.x.0/znp_CC1352P_2_other.syscfg
@@ -1,7 +1,7 @@
 /**
  * These arguments were used when this file was generated. They will be automatically applied on subsequent loads
  * via the GUI or CLI. Run CLI with '--help' for additional information on how to override these arguments.
- * @cliArgs --board "/ti/boards/CC1352P_2_LAUNCHXL" --rtos "tirtos7" --product "simplelink_cc13xx_cc26xx_sdk@7.10.00.98"
+ * @cliArgs --device "CC1352P1F3RGZ" --package "RGZ" --part "Default" --rtos "tirtos7" --product "simplelink_cc13xx_cc26xx_sdk@7.10.00.98"
  * @versions {"tool":"1.16.1+2960"}
  */

@@ -71,12 +71,11 @@ CCFG.ccfgTemplate.$name       = "ti_devices_CCFG_CCFGCC26XXTemplate0";

 rfdesign.rfDesign = "LAUNCHXL-CC1352P-2";

-Display1.$hardware               = system.deviceData.board.components.XDS110UART;
 Display1.$name                   = "CONFIG_DISPLAY";
 Display1.uart.$name              = "CONFIG_DISPLAY_UART";
 Display1.uart.uart.$assign       = "UART1";
-Display1.uart.uart.txPin.$assign = "boosterpack.4";
-Display1.uart.uart.rxPin.$assign = "boosterpack.3";
+Display1.uart.uart.txPin.$assign = "DIO_13";
+Display1.uart.uart.rxPin.$assign = "DIO_12";

 AESCBC1.$name = "CONFIG_AESCBC_0";

@@ -97,13 +96,15 @@ NVS1.internalFlash.regionBase = 0x50000;

 NVS2.$name                          = "CONFIG_NVSEXTERNAL";
 NVS2.nvsType                        = "External";
-NVS2.$hardware                      = system.deviceData.board.components.MX25R8035F;
 NVS2.externalFlash.$name            = "ti_drivers_nvs_NVSSPI25X0";
 NVS2.externalFlash.regionSize       = 0x256000;
 NVS2.externalFlash.verifyBufferSize = 64;

-RF.$hardware             = system.deviceData.board.components["SKY13317-373LF"];
-RF.rfAntennaPin0.$assign = "boosterpack.39";
+RF.rfAntennaPinSymbol0   = "CONFIG_RF_24GHZ";
+RF.rfAntennaPinSymbol1   = "CONFIG_RF_HIGH_PA";
+RF.rfAntennaPinSymbol2   = "CONFIG_RF_SUB1GHZ";
+RF.pinSelectionAntenna   = 3;
+RF.rfAntennaPin0.$assign = "DIO_6";
 RF.rfAntennaPin1.$assign = "DIO_5";
 RF.rfAntennaPin2.$assign = "DIO_30";

@@ -112,40 +113,37 @@ SHA21.$name = "CONFIG_SHA2_0";
 TRNG1.$name = "CONFIG_TRNG_0";

 Button1.$name          = "CONFIG_BTN_LEFT";
-Button1.$hardware      = system.deviceData.board.components["BTN-1"];
+Button1.button.$assign = "DIO_15";
 Button1.gpioPin.$name  = "CONFIG_GPIO_BTN1";
 Button1.gpioPin.pull   = "Pull Up";
-Button1.button.$assign = "boosterpack.13";

 Button2.$name          = "CONFIG_BTN_RIGHT";
-Button2.$hardware      = system.deviceData.board.components["BTN-2"];
+Button2.button.$assign = "DIO_14";
 Button2.gpioPin.$name  = "CONFIG_GPIO_BTN2";
 Button2.gpioPin.pull   = "Pull Up";
-Button2.button.$assign = "boosterpack.8";

 LED1.$name          = "CONFIG_LED_GREEN";
-LED1.$hardware      = system.deviceData.board.components.LED_GREEN;
-LED1.ledPin.$assign = "boosterpack.40";
+LED1.ledPin.$assign = "DIO_7";
 LED1.gpioPin.$name  = "CONFIG_GPIO_GLED";

 const NVSSPI25XDevice                        = scripting.addModule("/ti/drivers/nvs/NVSSPI25XDevice", {}, false);
 const NVSSPI25XDevice1                       = NVSSPI25XDevice.addInstance({}, false);
 NVSSPI25XDevice1.$name                       = "CONFIG_NVS_SPI_0";
 NVS2.externalFlash.spiFlashDevice            = NVSSPI25XDevice1;
-NVSSPI25XDevice1.chipSelect.$assign          = "boosterpack.38";
+NVSSPI25XDevice1.chipSelect.$assign          = "DIO_20";
 NVSSPI25XDevice1.chipSelectPinInstance.$name = "CONFIG_GPIO_0";

 SPI1.$name                         = "CONFIG_SPI_0";
 NVSSPI25XDevice1.sharedSpiInstance = SPI1;
+SPI1.spi.$assign                   = "SSI0";
+SPI1.spi.sclkPin.$assign           = "DIO_10";
+SPI1.spi.pociPin.$assign           = "DIO_8";
+SPI1.spi.picoPin.$assign           = "DIO_9";
+SPI1.spi.dmaRxChannel.$assign      = "DMA_CH3";
+SPI1.spi.dmaTxChannel.$assign      = "DMA_CH4";
 SPI1.sclkPinInstance.$name         = "CONFIG_PIN_SPI_SCLK";
 SPI1.pociPinInstance.$name         = "CONFIG_PIN_SPI_MISO";
 SPI1.picoPinInstance.$name         = "CONFIG_PIN_SPI_MOSI";
-SPI1.spi.$assign                   = "SSI0";
-SPI1.spi.sclkPin.$assign           = "boosterpack.7";
-SPI1.spi.pociPin.$assign           = "boosterpack.14";
-SPI1.spi.picoPin.$assign           = "boosterpack.15";
-SPI1.spi.dmaRxChannel.$assign      = "DMA_CH3";
-SPI1.spi.dmaTxChannel.$assign      = "DMA_CH4";

 BIOS.assertsEnabled = false;
 BIOS.rtsGateType    = "BIOS_GateMutexPri";

Having said that, we probably would want to do this for all boards anyway, as they are mostly not launchboards anyway, and assigning pins to non functional bits is probably a bad idea anyway. On the other hand, I doubt there's any other peripherials left anyway :p the buttons?

Oh, and shit, I forgot to test/check one thing, if the container building (and the pre-patching stuff) still works as expected. Been using a unpatched build env all this time so I could apply and test the patches; so there'll be a small change pushed still. But the conversation above can still be held.

Koenkk commented 2 months ago

One 'issue' I am still struggling with, is the 'others' target.

For the syscfg files, would it help to get rid of the re-save and try to check in the diff from the original file?

I think it would indeed be nicer to start working from the simplelink sdk fork (I guess we can get rid of the firmware patches then), soon I will release a new FW (https://github.com/Koenkk/Z-Stack-firmware/discussions/505) which is a good moment to start testing this.

oliv3r commented 2 months ago

One 'issue' I am still struggling with, is the 'others' target.

I figured it out :) So I learned that what basically happens is that we use a pre-configured board setup (the launcpads) which are linked to 'components' which are re-usable pre-configured blocks/chips, making it easier for the integrator just re-use common configurations. The leds, the RF switch etc. When your board is setup using these components, they are off-limits. Cannot be changed. By removing this (use hardware) and just using a normal 'RF' switch, it allows us to configure all settings manually. So by doing this to the RF switch (and/or the UART) we can make this configuration.

Diff the syscfg files and see :p the diff should be small, but alignment makes things jumps a bit.

diff -u --color znp_CC1352P_2_LAUNCHXL.syscfg znp_CC1352P_2_other.syscfg                                               2024-08-17 09:38:42 [0]
--- znp_CC1352P_2_LAUNCHXL.syscfg   2024-08-17 09:23:25.911776616 +0200
+++ znp_CC1352P_2_other.syscfg  2024-08-17 09:37:16.041693888 +0200
@@ -39,7 +39,6 @@
 const Button2      = Button.addInstance();
 const LED          = scripting.addModule("/ti/drivers/apps/LED");
 const LED1         = LED.addInstance();
-const LED2         = LED.addInstance();
 const Settings     = scripting.addModule("/ti/posix/tirtos/Settings");
 const BIOS         = scripting.addModule("/ti/sysbios/BIOS");
 const Boot         = scripting.addModule("/ti/sysbios/family/arm/cc26xx/Boot");
@@ -61,7 +60,7 @@
  * Write custom configuration values to the imported modules.
  */
 CCFG.xoscCapArray             = true;
-CCFG.xoscCapArrayDelta        = 0xC1;
+CCFG.xoscCapArrayDelta        = 0xFA;
 CCFG.enableBootloader         = true;
 CCFG.enableBootloaderBackdoor = true;
 CCFG.dioBootloaderBackdoor    = 15;
@@ -103,10 +102,11 @@
 NVS2.externalFlash.regionSize       = 0x256000;
 NVS2.externalFlash.verifyBufferSize = 64;

-RF.$hardware             = system.deviceData.board.components["SKY13317-373LF"];
-RF.rfAntennaPin0.$assign = "DIO_28";
-RF.rfAntennaPin1.$assign = "DIO_29";
-RF.rfAntennaPin2.$assign = "DIO_30";
+RF.pinSelectionAntenna   = 2;
+RF.rfAntennaPin0.$assign = "boosterpack.39";
+RF.rfAntennaPin1.$assign = "boosterpack.10";
+scripting.suppress("The board 'CC1352P-2 LaunchPad' requires the 'RF Antenna Switch' to be selected\\.", RF, "$hardware");
+scripting.suppress("Connected to hardware,@@@.+?@@@ is connected to LaunchPad LED Red on the CC1352P-2 LaunchPad\\. Consider selecting it in 'use hardware' above\\. @@@.+?@@@", RF, "rfAntennaPin0");

 SHA21.$name = "CONFIG_SHA2_0";

@@ -124,15 +124,10 @@
 Button2.gpioPin.pull   = "Pull Up";
 Button2.button.$assign = "boosterpack.8";

-LED1.$name          = "CONFIG_LED_RED";
-LED1.$hardware      = system.deviceData.board.components.LED_RED;
-LED1.ledPin.$assign = "boosterpack.39";
-LED1.gpioPin.$name  = "CONFIG_GPIO_RLED";
-
-LED2.$name          = "CONFIG_LED_GREEN";
-LED2.$hardware      = system.deviceData.board.components.LED_GREEN;
-LED2.ledPin.$assign = "boosterpack.40";
-LED2.gpioPin.$name  = "CONFIG_GPIO_GLED";
+LED1.$name          = "CONFIG_LED_GREEN";
+LED1.$hardware      = system.deviceData.board.components.LED_GREEN;
+LED1.ledPin.$assign = "boosterpack.40";
+LED1.gpioPin.$name  = "CONFIG_GPIO_GLED";

 const NVSSPI25XDevice                        = scripting.addModule("/ti/drivers/nvs/NVSSPI25XDevice", {}, false);
 const NVSSPI25XDevice1                       = NVSSPI25XDevice.addInstance({}, false);

HOWEVER! By dropping the rfswitch component, it complains still with

you_must_implement_rfDriverCallbackAntennaSwitching_see_generated_ti_drivers_config_c_in_debug_folder_or_sysconfig_preview ./syscfg/ti_drivers_config.o

Which I realize is on purpose. Just gotta figure out the magic voodoo that is used by the 'component' to trick things and use the 'standard' files.

For the syscfg files, would it help to get rid of the re-save and try to check in the diff from the original file?

That's what I'm doing right now. But re-saves do trigger some need for manual intervention. At least the Idle1 often gets renamed to Idle2. I haven't found it in the UI yet to see if it has a 'lock down' mode. Ironically, The UI initially added it as Idle1 itself ...

I think it would indeed be nicer to start working from the simplelink sdk fork (I guess we can get rid of the firmware patches then), soon I will release a new FW (#505) which is a good moment to start testing this.

I have a small todo;

And as you see, I also wanted to use the git SDK; but hit a snag there. Doing so will get rid of the manual git format-patch; git add *.patch effort. But I have to figure out how the eclipse/SDK figures out what files to pull. I know there's variables that set versions in the examples, but anyway. I just realized, that the SDK isn't even installed, just unzipped; so can't be hard ... To get the SDK in; it's probably best/easiest to fork the original 2 repo's, then add mine as a remote, and push my branch to the yours (so all git hashes are identical) and we can go from there. https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1401502/codecomposer-using-the-git-version-of-the-sdk-instead-of-the-zip-requires-incantations-that-are-not-clear

And yes, generating the file would be nice, but might not be possible. I think (but not sure) that the GUI syscfonfig uses some sdk javascript to generate stuff, which you can't do from the console. But I think that's alright, we should be (as I did here) commit the znp.syscfg to the repo anyway because some of these changes would be really hard to script, and patching a generated znp.syscfg is bad anyway (see my 2nd commit in this series, but there's more).

I saw #505 and am testing it a bit as well (it's my 'is my hardware broken or is my patch not working firmware :p). I have since started to cherry-pick my patches to the new SDK branch; but they (finally?) changed the line-endings (LF instead of CTRLF) but all patches don't apply. Easy to fix, but painful. Or maybe things went differently when checking out, but I doubt that ... Where is your firmware.patch to see if there's any differences? I just did dos2unix on the patch files and applied them, that went cleanly without any conflict, so I wonder if you changed anything at all?

oliv3r commented 2 months ago

Anyway, I've left this commit at the container build stage, (pushed the other stuff to a different branch) so we could get this merged with the early couple of patches.

I'll open a new MR, maybe mostly for archival purposes for the current versions, and another one with the new SDK stuff to get started from that point first.

Koenkk commented 2 months ago

Where is your firmware.patch to see if there's any differences?

I don't have a patch published yet, I will release it next Saturday. Then we can also test out these changes against that.

oliv3r commented 2 months ago

Where is your firmware.patch to see if there's any differences?

I don't have a patch published yet, I will release it next Saturday. Then we can also test out these changes against that.

Cool; well I actually patched it myself, but of course don't know any additional patches you've added :)

Meanwhile, I found out how to use the SDK from GIT https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1401502/codecomposer-using-the-git-version-of-the-sdk-instead-of-the-zip-requires-incantations-that-are-not-clear but it's not working yet. But getting closer and seems that it should be possible. Just not yet while importing :S

oliv3r commented 2 months ago

@Koenkk success :)

It is now possible to build using the SDK as git repo! i'm pushing here only the initial container related changes as per initial scope of this MR. I'll open a nother MR with the progressive changes to use the SDK.

511 is part of this MR by accident, but once that one would be merged, a rebase will make it go away ;)

Koenkk commented 2 months ago

Great, I'll update the repo soon with the new firmware, than we can start testing this further.

Koenkk commented 2 months ago

I've released the 20240710 firmware. I guess the following things need to be done:

Let me know if that is OK

oliv3r commented 2 months ago

@Koenkk I saw your firmware release, and done the changes work. So the steps needed

Merge #515 :p and then I need to rebase, and actually then this small MR, but

Almost correct, forking the repo on github is fine, but also fork https://github.com/TexasInstruments/simplelink-zstack-examples so that the relation to the TI repo is setup correctly for both.

Don't clone them however, instead clone/pull this branch instead of your own repo, which adds the examples repo as a submodule.

Next within the submodules, we need to add my remote, git remote add oliv3r https://github.com/oliv3r/simplelink-zstack-examples. This is needed because I already setup the repo to be yours already, but obviously the content won't be there yet. You should be git submodule update --init now, as the correct hashes now exist from the pull. Push these changes to your own repo and delete my remote.

The same needs to be done for the SDK, https://github.com/oliv3r/simplelink-lowpower-f2-sdk. You don't need the last few commits on that branch, but the examples repo won't refer to them.

But this we should probably discuss in my new MR; https://github.com/Koenkk/Z-Stack-firmware/pull/516

Koenkk commented 1 month ago

I see, let's first focus on https://github.com/Koenkk/Z-Stack-firmware/pull/516, I ran into a blocking issue on Mac: https://github.com/Koenkk/Z-Stack-firmware/pull/516#issuecomment-2365319711

github-actions[bot] commented 1 day ago

This pull request is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days