Fix nrf sdk download links #2270
Merged
+3
−3
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It seems like NRF has moved the download to a new location- Update the build script to fetch from the same URL the download website currently provides.
|
Build size and comparison to main:
|
mark9064
added
documentation
mark9064
approved these changes
Mar 13, 2025
Collaborator
|
@dariusarnold Do you know if those URLs are still hosted by Nordic and if they are "official"? The domain name does not seem to be directly linked to Nordic Semiconductor. |
Member
|
It's official, you can find them on the nordic website See here https://www.nordicsemi.com/Products/Development-software/nRF5-SDK/Download#infotabs |
Collaborator
|
Oh yes, right! I previously clicked on the big "Download files (.zip)" button and did not notice that I could simply click on the name of the package! |
JF002
approved these changes
May 21, 2025
Closed
NeroBurner
added a commit
that referenced
this pull request
May 24, 2025
The upstream NRF-SDK download url and zip archive filename changed, which was fixed with #2270 But the archive contents stayed the same, with the "old" folder name. After #2270 we have basically the same docker-container as before the PR, but the `GetNrfSdk` function of the `build.sh` script is called again during firmware build time as the expected foldername for the SDK isn't the same as the zip filename: ```sh [ ! -d "$TOOLS_DIR/$NRF_SDK_VER" ] && GetNrfSdk ``` Then during the build the `buils.sh` script tries to execute `GetNrfSdk` again, which fails as the files already exist resulting in the following error: ``` replace /opt/nRF5_SDK_15.3.0_59ac345/components/802_15_4/api/HAL/hal_atomic.h? [y]es, [n]o, [A]ll, [N]one, [r]ename: NULL ``` Fix this by reverting the `NRF_SDK_VER` to the folder name in the zip archive and by some character replacement generate the download URL from the above (the download is in lower-case without the `_` and `.` characters). Furthermore add safeguards to check after the `GetNrfSdk` call if the expected folder is really created. Then we have an error early during container image creation if the contents of the zip-archive are unexpected.
NeroBurner
added a commit
that referenced
this pull request
May 27, 2025
The upstream NRF-SDK download url and zip archive filename changed, which was fixed with #2270 But the archive contents stayed the same, with the "old" folder name. After #2270 we have basically the same docker-container as before the PR, but the `GetNrfSdk` function of the `build.sh` script is called again during firmware build time as the expected foldername for the SDK isn't the same as the zip filename: ```sh [ ! -d "$TOOLS_DIR/$NRF_SDK_VER" ] && GetNrfSdk ``` Then during the build the `buils.sh` script tries to execute `GetNrfSdk` again, which fails as the files already exist resulting in the following error: ``` replace /opt/nRF5_SDK_15.3.0_59ac345/components/802_15_4/api/HAL/hal_atomic.h? [y]es, [n]o, [A]ll, [N]one, [r]ename: NULL ``` Fix this by reverting the `NRF_SDK_VER` to the folder name in the zip archive and by some character replacement generate the download URL from the above (the download is in lower-case without the `_` and `.` characters). Furthermore add safeguards to check after the `GetNrfSdk` call if the expected folder is really created. Then we have an error early during container image creation if the contents of the zip-archive are unexpected.
JustScott
pushed a commit
to JustScott/InfiniTime
that referenced
this pull request
Jul 29, 2025
nRF has moved the download to a new location- Update the build script to fetch from the same URL the download website currently provides.
JustScott
pushed a commit
to JustScott/InfiniTime
that referenced
this pull request
Jul 29, 2025
) The upstream NRF-SDK download url and zip archive filename changed, which was fixed with InfiniTimeOrg#2270 But the archive contents stayed the same, with the "old" folder name. After InfiniTimeOrg#2270 we have basically the same docker-container as before the PR, but the `GetNrfSdk` function of the `build.sh` script is called again during firmware build time as the expected foldername for the SDK isn't the same as the zip filename: ```sh [ ! -d "$TOOLS_DIR/$NRF_SDK_VER" ] && GetNrfSdk ``` Then during the build the `buils.sh` script tries to execute `GetNrfSdk` again, which fails as the files already exist resulting in the following error: ``` replace /opt/nRF5_SDK_15.3.0_59ac345/components/802_15_4/api/HAL/hal_atomic.h? [y]es, [n]o, [A]ll, [N]one, [r]ename: NULL ``` Fix this by reverting the `NRF_SDK_VER` to the folder name in the zip archive and by some character replacement generate the download URL from the above (the download is in lower-case without the `_` and `.` characters). Furthermore add safeguards to check after the `GetNrfSdk` call if the expected folder is really created. Then we have an error early during container image creation if the contents of the zip-archive are unexpected.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It appears that NRF has moved the download to a new location. The old URL is now a 404.
Update the build script and README to use the same URL the download website currently provides.
Fixes #2267