I recently uprev'ed my project from wiced sdk v126.96.36.199 to v188.8.131.52. The API changes were not a big deal, but I just noticed that the "download_apps" build option no longer properly controls for builds with 184.108.40.206.
In all the previous sdk's we've used (4.0, 4.1, 5.2, 6.0, 6.1), that build option would cause the build to download all the external flash components as well as the internal flash components. So we'd typically have two build targets - one that included "download_apps" and one that did not. We'd use the first for initial builds to guarantee ( or clear ) the proper external flash contents, but during app debugging cycles, we'd use the second as it's much faster.
But as of 220.127.116.11, builds from WiCED studio always download external flash components regardless of the presence of that build option in the target string.
Searching the forums and the recent release notes (up through 6.2.1) have not provided any hints.
Has anyone else seen this?
I have traced this as far as attributing the change in behavior specifically to the changes made inside standard_platform_targets.mk between sdks 18.104.22.168 and 22.214.171.124.
If I simply copy the 126.96.36.199 version of that file to my 188.8.131.52 tools/makefile directory, then download_apps goes back to working as before.
I don't know what issues or features those changes were for, nor have I tried to figure out which of the changes in that file actually caused download_apps to break ( life's to short to debug the wiced make system ) but given the targets involved in the changes I can see how they might have broken something.
For now I'll use the 184.108.40.206 version of standard_platform_targets.mk as a workaround as everything seems to be functioning correctly with those builds.
But it would be nice if someone from Cypress could provide a real answer.
The usage of download_apps to download into external flash is dependent on the RESOURCES_LOCATION.
- If RESOURCES_LOCATION := RESOURCES_IN_WICEDFS then download_apps is not required to download fw and CLM blob into extrenal flash.
Make target with "download run" or "download_apps download run" is equivalent. The resources are by defualt downloaded into external flash.
- If the fw and CLM blob are configured as direct resources using RESOURCES_LOCATION := RESOURCES_IN_DIRECT_RESOURCES. Make won't force download_apps and it will keep the old behavior.
But alas, I cannot consider that reply an answer as it does not solve the actual issue.
We have had RESOURCES_LOCATION:=RESOURCES_IN_WICEDFS since 5.2. This change to make resource loading the default in such a case appeared in 6.2.
And the fundamental issue is that loading external flash with every build is both unnecessary and VERY time consuming. That seriously slows down the debugging cycle.
I cannot use DIRECT_RESOURCES and shouldn't have to.
So my question remains - with 220.127.116.11 and RESOURCES_IN_WICEDFS, how can I construct a WicedStudio build target that downloads the dct, bootloader, and app WITHOUT downloading the resources? Phrased another way, now that Cypress has made download_app the default, how do I turn it off?
If there is no way to do so, then I would argue that 18.104.22.168 is not useable for normal development.
I believe you want the resources in external flash but don't wish to load the external flash with every build. Am I correct?
Yes riya that is correct.
This was possible for all the SDK versions before 22.214.171.124 (by simply not including download_apps).
The difference in flashing time is substantial (for my C4343W project, it's 7 seconds vs a minute). And the external flash contents change very seldom.
So I don't object to Cypress changing the default behavior of builds, but I would argue that good development support requires there be a way to override the default.
If FW/CLM Blob file are not modified, then the extrernal flash writer will not write them to external flash, it compares the external flash with data to be written and does nothing if they are same. The time increased while downloading is just the overhead of reading the external flash for every download.
The download_apps flag usage is forced because the CLM blob and fw are handled as separate resources and if download_apps is not included when a new board is programmed for the first time, the application wont be able to load.(which signals an erroneous behavior even when there is no problem in the board)
So your answer is that there is no way to override the new default. And yes I already knew I could use the previous makefile as a workaround (per my original posts).
And I'm trying to migrate to 6.2 - that's what the thread is about.
Does cypress plan to address the shortcomings of this recent build change in upcoming releases?
No @mifi that 5.2 note does not address the change in question. The change in question occurred in the 126.96.36.199 release (as noted). That 5.2 change said basically " as of 5.2, you must always use the download_apps option" . The change in 188.8.131.52 was to default all builds to act as if the (old) download_apps option was specified.
It is that latter change that was (a) not documented in the 6.2 release notes and (b) which provides no override.