Frustrating to upgrade to 5.0

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

cross mob
Anonymous
Not applicable

I spent yesterday and today trying to upgrade the SDK from 4.0 to 5.0 and it's been really frustrating. I'm still not done with the migration after 2 days.

1) Why does the IDE have to be bundled with the SDK? Installing a new IDE throws away all my previous customizations made in Eclipse, including code color, fonts, indentation rules, etc. I know I could port the new SDK back to the old IDE, but it's just painful and time-wasting. It also increases download time and disk requirements for installing

2) The new SDK breaks build (for example, there's an extra #define PLATFORM_FACTORY_RESET_TIMEOUT in wiced_waf_common.h what wasn't there before, breaking build), forcing us to update all platform files which otherwise wouldn't be necessary.

3) The Linux version of the SDK have all the line encodings in Windows-style. This is totally unacceptable. I have a bunch of patch files that modifies the SDK because it doesn't work right out of the box. The patch files won't work since in Linux, our patch files are checked out from Git with LF ending. We are constantly switching between Windows and Linux and we need to have a SDK that works equally well on all platforms.

4) I haven't been able to get the OpenOCD tool that came with the SDK 5.0 to work. It just segfaults in Eclipse and I still haven't figured out why.

I want to point out there are IDE+SDKs out there that work beautifully across updates. Android Studio for example updates SDK separately from your workspace and you don't have to mess with a lot of things. But even for starters, making sure your SDK works right out of the box should be the bare minimum.

19 Replies
Anonymous
Not applicable

Okay I uninstalled and tried a fresh install and right out of the box, snip.scan-BCM943362WCD4 doesn't build. Windows 10 Home x64 w/ Creators Update (Version 1703 Build 15063.296).

Building Bootloader

tools/makefiles/standard_platform_targets.mk:194: recipe for target 'generated_mac_address.txt' failed

make.exe[1]: *** [generated_mac_address.txt] Error -1073741502

make.exe[1]: *** Waiting for unfinished jobs....

make.exe[3]: *** [build/waf.bootloader-NoOS-BCM943362WCD4/generated_security_dct.h] Error -1073741502

make.exe[3]: *** Waiting for unfinished jobs....

make.exe[2]: *** [main_app] Error 2

tools/makefiles/standard_platform_targets.mk:81: recipe for target 'bootloader' failed

make.exe[1]: *** [bootloader] Error 2

Makefile:348: recipe for target 'main_app' failed

make: *** [main_app] Error 2

Again, probably problem with perl.exe. If you go into tools/common/Win32/ and run "perl.exe -v" nothing comes up. Even if I replace that perl.exe with my own Cygwin perl.exe, build still fails to generate "generated_mac_address.txt" when invoked from make.exe. However, running the same command in Bash shell from VERBOSE output can generate the file fine (after replacing the perl.exe).

0 Likes

josh.yu_1995211

I asked several people internally to recreate the issue on Win 10 and they were unable to do so.

Could you find the install logs and attach them to this discussion.

You can type %tmp% from File->Search and find the temp directory used to store the WICED install logs (normally in your specific User Temp folder).

0 Likes

Adding the level 1 applications team.

grsr lsri rash mady gsns ankh

I have also shared your install logs with the developers and ask them to look into this with Level 1 and make recommendations.

0 Likes

You may also want to create a case on Cypress.com (MyCases once you login) as this will help the Level 1/2 teams track the issue.

0 Likes

Based on what we've experienced, this might have been an issue since 3.5.2.

Not suggesting this as a solution, but rolling back to 3.1.2 seems to have fixed it for us.

0 Likes
GauravS_31
Moderator
Moderator
Moderator
10 questions asked 250 solutions authored 250 sign-ins

I discussed the 4 points internally and here are the responses:

1. We don't see this as a major issue. You can use switch workspace in eclipse to switch to a different version of WICED SDK if required.

2. The workaround here is to comment out the #define PLATFORM_FACTORY_RESET_TIMEOUT in platform.h. This is what I always do whenever I copy BCM94343W_AVN platform to a new SDK version.

3. I have noted this point and raised a ticket internally on this.

4. There is a workaround available in this blog post https://community.cypress.com/community/wiced-wifi/wiced-wifi-forums/blog/2015/05/22/wiced-ota-sdk-3... for this issue.

Regarding your build problem in Windows 10 64-bit, I could not recreate this issue. It compiled and worked fine in Windows 10 64-bit after I executed the dpinst_x64.exe to install the drivers.

grsr wrote:

4. There is a workaround available in this blog post https://community.cypress.com/community/wiced-wifi/wiced-wifi-forums/blog/2015/05/22/wiced-ota-sdk-3... for this issue.

You provide a link posted 2 years ago.

My question is why Cypress does not fix it properly in new sdk but keep asking users to use a "workaround"?

0 Likes

I will relay your message to the software team and get back to you.

0 Likes

grsr wrote:

2. The workaround here is to comment out the #define PLATFORM_FACTORY_RESET_TIMEOUT in platform.h. This is what I always do whenever I copy BCM94343W_AVN platform to a new SDK version.

I hit build failure due to redefine of PLATFORM_FACTORY_RESET_TIMEOUT in latest SDK.

Take a look at:

././WICED/platform/MCU/STM32F4xx/../wiced_waf_common.h

It even has #ifndef PLATFORM_FACTORY_RESET_TIMEOUT guard.

Which means the default PLATFORM_FACTORY_RESET_TIMEOUT is used only when PLATFORM_FACTORY_RESET_TIMEOUT is not defined.

This actually means a sdk bug, just comment out the #define PLATFORM_FACTORY_RESET_TIMEOUT in platform.h is wrong.

The reason to have PLATFORM_FACTORY_RESET_TIMEOUT in platform.h is to allows users to build different platforms

with differet PLATFORM_FACTORY_RESET_TIMEOUT setting. It no longer work now.

This needs fix properly.

0 Likes

grsr wrote:

3. I have noted this point and raised a ticket internally on this.

There is a gap between "raised a ticket internally" and deliver the fix.

1 month after your reply, sill has all the line encodings in Windows-style in sdk-5.1.

When will this get fix?

0 Likes

grsr wrote:

I discussed the 4 points internally and here are the responses:

1. We don't see this as a major issue. You can use switch workspace in eclipse to switch to a different version of WICED SDK if required.

2. The workaround here is to comment out the #define PLATFORM_FACTORY_RESET_TIMEOUT in platform.h. This is what I always do whenever I copy BCM94343W_AVN platform to a new SDK version.

3. I have noted this point and raised a ticket internally on this.

4. There is a workaround available in this blog post https://community.cypress.com/community/wiced-wifi/wiced-wifi-forums/blog/2015/05/22/wiced-ota-sdk-3... for this issue.

Regarding your build problem in Windows 10 64-bit, I could not recreate this issue. It compiled and worked fine in Windows 10 64-bit after I executed the dpinst_x64.exe to install the drivers.

sdk-5.2 does not include the fix for 2, 3, and 4.

0 Likes

Issue 2 has been resolved and fix is expected to be available in WICED 6.x. Regarding issue 4 (seg fault), can you check if this change works on your linux system? Go to tools/makefiles/standard_platform_targets.mk. Replace copy_bootloader_output_for_eclipse: build_done at line 104 with copy_bootloader_output_for_eclipse: build_done APPS_LOOKUP_TABLE_RULES and then build the project.

0 Likes

It's not clear to me about the change you mentioned.

If you can provide a diff that would be good.

But to make it clear, I don't use eclipse at all.

On linux development environment, I can just run make command directly.

And the segmentation fault is obviously related to "make".

(The make version is too old)

0 Likes
lock attach
Attachments are accessible only for community members.

I have attached the diff.

0 Likes

grsr wrote:

I have attached the diff.

Your change will cause a buld regression:

For example, edit ota_fr.mk and change FR_APP to snip.scan.

Now build ota_fr without snip.scan will hit error:

$ ./make snip.ota_fr-FreeRTOS-LwIP-BCM94343WWCD2

MAKEFILE MAKECMDGOALS=snip.ota_fr-FreeRTOS-LwIP-BCM94343WWCD2 OTA2_SUPPORT is disabled

Building Bootloader

make[1]: *** No rule to make target `build/snip.scan-FreeRTOS-LwIP-BCM94343WWCD2/binary/snip.scan-FreeRTOS-LwIP-BCM94343WWCD2.stripped.elf', needed by `APPS_LOOKUP_TABLE_RULES'.  Stop.

make[1]: *** Waiting for unfinished jobs...

axel.lin_1746341 wrote:

grsr wrote:

I have attached the diff.

Your change will cause a buld regression:

For example, edit ota_fr.mk and change FR_APP to snip.scan.

Now build ota_fr without snip.scan will hit error:

$ ./make snip.ota_fr-FreeRTOS-LwIP-BCM94343WWCD2

MAKEFILE MAKECMDGOALS=snip.ota_fr-FreeRTOS-LwIP-BCM94343WWCD2 OTA2_SUPPORT is disabled

Building Bootloader

make[1]: *** No rule to make target `build/snip.scan-FreeRTOS-LwIP-BCM94343WWCD2/binary/snip.scan-FreeRTOS-LwIP-BCM94343WWCD2.stripped.elf', needed by `APPS_LOOKUP_TABLE_RULES'.  Stop.

make[1]: *** Waiting for unfinished jobs...

Add vikr

0 Likes

vikr

I hit below error again with sdk-6.0.

Segmentation fault (core dumped)

make: *** [main_app] Error 139

0 Likes

grsr wrote:

Issue 2 has been resolved and fix is expected to be available in WICED 6.x. Regarding issue 4 (seg fault), can you check if this change works on your linux system? Go to tools/makefiles/standard_platform_targets.mk. Replace copy_bootloader_output_for_eclipse: build_done at line 104 with copy_bootloader_output_for_eclipse: build_done APPS_LOOKUP_TABLE_RULES and then build the project.

grsr

I already told you that this change causes build regression but such change is in sdk-6.0.0 now.

Besides, the make binary version is still the same.

i.e. no bug fix, but new regression introduced.