I have traced this as far as attributing the change in behavior specifically to the changes made inside standard_platform_targets.mk between sdks 126.96.36.199 and 188.8.131.52.
If I simply copy the 184.108.40.206 version of that file to my 220.127.116.11 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 18.104.22.168 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.
1 of 1 people found this helpful
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 22.214.171.124 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 126.96.36.199 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 PriyaM_16 that is correct.
This was possible for all the SDK versions before 188.8.131.52 (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.
1 of 3 people found this helpful
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)
1 of 1 people found this helpful
PriyaM_16 Thanks for the explanation of why cypress changed the default behavior.
But you still haven't actually answered my question. How can I override this default build behavior with 6.2?
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 184.108.40.206 release (as noted). That 5.2 change said basically " as of 5.2, you must always use the download_apps option" . The change in 220.127.116.11 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.
Ok. I missed this. Thanks for the clarification.