Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

Wi-Fi Combo Forum Discussions

rashc_2727106
Level 4
Level 4
10 likes received First like received First like given

I recently uprev'ed my project from wiced sdk v6.1.0.85 to v6.2.0.72.  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 6.2.0.72.

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 6.2.0.72, 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?

0 Likes
13 Replies
rashc_2727106
Level 4
Level 4
10 likes received First like received First like given

I have traced this as far as attributing the change in behavior specifically to the changes made inside standard_platform_targets.mk between sdks 6.1.0.85 and 6.2.0.72.

If I simply copy the 6.1.0.85 version of that file to my 6.2.0.72 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 6.1.0.85 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.

0 Likes

Adding a few members of the Applications team: grsr riya rroy zhez zhxh yans kavs shjl

0 Likes
PriyaM_16
Moderator
Moderator
Moderator
25 solutions authored 10 solutions authored 5 solutions authored

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.

mifo riya​  Thanks for the prompt response.

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 6.2.0.72 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 6.2.0.72 is not useable for normal development.

0 Likes
PriyaM_16
Moderator
Moderator
Moderator
25 solutions authored 10 solutions authored 5 solutions authored

I believe you want the resources in external flash but don't wish to load the external flash with every build. Am I correct?

0 Likes

Yes riya that is correct.

This was possible for all the SDK versions before 6.2.0.72 (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.

0 Likes

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)

riya​  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?  

Hello rsh_2727106

You can use the previous SDK makefile to revert to the earlier behavior but we do not recommend it. We would like you to migrate to the latest sdk.

riya

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?

rsh_2727106

The download_apps architectural change was outlined in the version 5.2 Release Notes:

Release Notes: WICED Studio 5.2.0

pastedImage_0.png

tgevikr

0 Likes

No @mifi that 5.2 note does not address the change in question.  The change in question occurred in the 6.2.0.72 release (as noted).  That 5.2 change said basically " as of 5.2, you must always use the download_apps option" .  The change in 6.2.0.72 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.

0 Likes