Annoying behaviour in SDK 2.1.0

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

cross mob
StBa_721356
Level 5
Level 5
50 likes received 25 likes received 10 likes received

After migrating from SDK 2.0.1 to SDK 2.1.0 we found a very annoying issue.

After successfully building and downloading a new app from within the Eclipse IDE the following message appears:

Move DIP switch 2 of SW4 to off position and push Reset button to start application

This means that DIP switch 2 of SW4 has to be switched to the on position before downloading the app and then be switched to off to launch the app.

We tested this on both Linux and MacOS. We haven't tested this on Windows yet.

Our concern is that changing the state of this DIP switch will eventually lead into a mechanical failure of the DIP switch because such switches are not made for this.

Why is this necessary? In SDK 2.0.1 it works without changing the DIP switch all the time.

1 Solution
Anonymous
Not applicable

It looks like this behaviour is implemented in spar_setup.c (look for uart_IsConnected()).

Commenting out those #ifndef DEBUG sections will revert back to the previous behaviour.

Compiling your app with DEBUG=1 also seems to do the trick, but be aware that this also disables the watchdog and sleep.  Or so says the ./make documentation:

  [DEBUG=1|0]

    Enable or disable debug code in application. When DEBUG=1, watchdog will be disabled,

    sleep will be disabled and the app may optionally wait in a while(1) for the debugger

    to connect

I'm taking the DEBUG route.  I'll report back if I see smoke coming out.

Cheers,

View solution in original post

11 Replies
MichaelF_56
Moderator
Moderator
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

Confused.  Only the Windows version of the 2.1.0 installer has been posted to the website so far?

Did you modify the .7z archive for both MAC and Linux?

Note that others are having some issues with the Windows installer, so I expect some of these issues may be getting replicated to the version of the SDK you are using.

I will alert the development team of the issue.

arvinds j.t victorz

0 Likes

Yes, I meant the 7z file for Mac and Linux. This was posted at the same time as the Windows IDE installer.

0 Likes

As it turns out, it looks like this feature is by-design and does not represent a problem with the Windows based installer.

This fix essentially addresses an issue we experienced where when application exceed a certain size, downloads will fail unexpectandantly based on the minidriver needing to be pushed into RAM prior to commencing the application download.

Previously, the only work around for this issue was to initiatiate a recovery process.

0 Likes
Anonymous
Not applicable

Hi mwf_mmfae,

I don't think your answer addresses the OP's issue. 

I can confirm that the annoying behaviour reported by sbs is also present on Linux.  It used to be that we could download our app and run it right away on multiple boards at once.   Now we have to manually switch the DIP switch on each board, and switch it back before a new update.  This slows down considerably development and testing.  In fact we will not update to the new SDK until this is resolved.

Is there any way to disable this new behaviour?   (By the way, we were never affected by the bug that this change intends to fix)

Thanks,

Javier

0 Likes
Anonymous
Not applicable

I am also using Linux and found this new behavior very annoying in SDK 2.1.0.

Also I never encounter any download failure when using SDK 2.0.1 where I did not have to move the switch.

0 Likes
MiTo_1583836
Level 5
Level 5
50 likes received 25 likes received 10 likes received

I experienced the same issue as described by SBS on Windows last Friday with a 20736 Broadcom based platform (I did not try on the official TAG). I will redo the full install today and perform a build and download to the TAG board, let's see if I can get the message.

0 Likes
Anonymous
Not applicable

It looks like this behaviour is implemented in spar_setup.c (look for uart_IsConnected()).

Commenting out those #ifndef DEBUG sections will revert back to the previous behaviour.

Compiling your app with DEBUG=1 also seems to do the trick, but be aware that this also disables the watchdog and sleep.  Or so says the ./make documentation:

  [DEBUG=1|0]

    Enable or disable debug code in application. When DEBUG=1, watchdog will be disabled,

    sleep will be disabled and the app may optionally wait in a while(1) for the debugger

    to connect

I'm taking the DEBUG route.  I'll report back if I see smoke coming out.

Cheers,

Note that this will be fixed in SDK 2.1.1.

So once you upgrade, it will start to work like before....

0 Likes
Anonymous
Not applicable

When are you planning on releasing SDK 2.1.1 ?

0 Likes

SDK 2.1.1 for the Mac is now available: WICED-Smart-SDK-2.1.1-IDE-Installer.zip

Anonymous
Not applicable

Thanks for the update.  In the meantime you might want to mark my last response as correct, in case folks don't want/can't wait for 2.1.1.  Seems to be working well for me.

Cheers,

0 Likes