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.
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.
Yes, I meant the 7z file for Mac and Linux. This was posted at the same time as the Windows IDE installer.
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.
I don't think your answer addresses the OP's issue.
I can confirm that the annoying behaviour reported by StBa_721356 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)
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.
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:
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
I'm taking the DEBUG route. I'll report back if I see smoke coming out.
Note that this will be fixed in SDK 2.1.1.
So once you upgrade, it will start to work like before....
When are you planning on releasing SDK 2.1.1 ?
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.