CI: Add automated container build for Z-Stack 3.x.0 #507
Conversation
oliv3r
changed the title
|
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 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 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 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. |
|
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? |
|
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 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. |
|
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. |
|
@oliv3r I'm wondering if you can run the the sysconfig from the container somehow, I think a simple save action should be enough. |
|
Sysconf is installed, so just gotta gigure out the magic ;)
|
|
@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 So then I figured, well lets try to modify this project 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 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 |
|
@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 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, Was this intended? Or did you just forget to Other then that, I am able to build firmwares now, and am about to try them on my stick, hoping it won't brick :) |
|
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: ) + 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 :) 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? would work the same, no? (Caution with those undefs, it would hide the error, but the used value is actually from the 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) 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 Do pardon my ignorance :p but 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 (i'd assume that all of these pins need to be pre-assigned to fixed values ... randomly assigned pin values are never nice ;p) |
oliv3r
force-pushed
the
build
branch
5 times, most recently
from
9900582 to
47c3d4b
Compare
|
These files are initially generated but then slightly modified (all lines which have |
|
I got myself stuck in a little corner, no idea (yet) what went wrong, but while I can flash the firmware, using 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 |
|
@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 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 "[email protected]"
+ * @cliArgs --device "CC1352P1F3RGZ" --package "RGZ" --part "Default" --rtos "tirtos7" --product "[email protected]"
* @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. |
oliv3r
force-pushed
the
build
branch
3 times, most recently
from
448def8 to
ec35e38
Compare
For the 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. |
oliv3r
force-pushed
the
build
branch
2 times, most recently
from
3a38604 to
0fbdca2
Compare
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 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.
That's what I'm doing right now. But re-saves do trigger some need for manual intervention. At least the
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 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 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? |
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 |
|
@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 ;) |
oliv3r
force-pushed
the
build
branch
3 times, most recently
from
2072fd6 to
c2c18ef
Compare
|
Great, I'll update the repo soon with the new firmware, than we can start testing this further. |
|
I've released the 20240710 firmware. I guess the following things need to be done:
Let me know if that is OK |
|
@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, The same needs to be done for the SDK, But this we should probably discuss in my new MR; #516 |
oliv3r
force-pushed
the
build
branch
2 times, most recently
from
67f35ba to
a31eff9
Compare
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). Signed-off-by: Olliver Schinagl <[email protected]>
|
I see, let's first focus on #516, I ran into a blocking issue on Mac: #516 (comment) |
|
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 |
sounds good to me! Give me some time to look at that ... |
| # Prefix args with $bin if $1 is not a valid command | ||
| if ! command -v -- "${1:-}" > '/dev/null' 2>&1; then | ||
| # Always register the SDK on a valid command | ||
| eclipse -noSplash -application com.ti.common.core.initialize -ccs.productDiscoveryPath "${SLF2_SDK}" |
There was a problem hiding this comment.
Sorry to intrude, but I think you forgot to define SLF2_SDK. I'm not sending a PR because you seem to be in the middle of a very complex operation involving a few repos.
| --rm \ | ||
| --tty \ | ||
| --volume './:/src' \ | ||
| --volume '../../simplelink_f2_examples_sdk:/sdk' \ |
There was a problem hiding this comment.
Here, docker doens't like the volume name (https://stackoverflow.com/questions/60369990/error-installing-nextcloud-with-docker-compose ) so I used "$PWD/../../simplelink_f2_examples_sdk:/sdk"
| ARG SLF2_COMPONENTS="PF_CC2X" | ||
| ENV SLF2_COMPONENTS="${SLF2_COMPONENTS}" | ||
|
|
||
| ARG CCS_VERSION="12.5.0" |
There was a problem hiding this comment.
You might need to bump the version, bacause the patch expect Sysconfig 18.1+ but the version 18.0 is delivered in this version of CCS
Error: SimpleLink Low Power F2 SDK version 7.41.00.17 requires at least version 1.18.1 of SysConfig.
When bumping to 12.6.0, the SLF2_COMPONENTS get renamed to PF_WCONN
|
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 |
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).