Should I update from CCSv3.3 toolchain?

I have a question related to my previous post:

"Legacy TMS320VC5502 project with updated C5500 compiler version 4.4.1"
http://e2e.ti.com/support/development_tools/compiler/f/343/p/194892/696779.aspx#696779

I am updating the toolchain for a pair of legacy TMS320VC5502 applications that run on two DSPs in our product.
I am having some trouble getting the applications to run properly with my updated environment. I will provide a short summary below.
I will continue to troubleshoot that from a functional point of view.
In the meantime, I pose these questions to this E2E forum:

1) Are there known issues with the following tools related to task switching, hardware interrupt (HWI) handling, software interrupt (SWI) handling?

Code Composer Studio (CCS) v3.3.38.2
DSP/BIOS v5.31.02
Chip Support Library v2.31.00.9
DSPLIB v2.40.00
Code Generation Tools v3.3.2

2) Should I drop everything and update any of these tools to more recent releases immediately? In particular, DSP/BIOS 5.31.09 perhaps? Or newer?

----------
Some history:

Previous development for the two VC5502 applications was done with the following toolchain:

Code Composer Studio (CCS) v2.21.00
Code Generation Tools 2.56
DSP/BIOS 4.90.00.5 (including Chip Support Library (CSL))
DSPLIB 2.20.02

The applications have been routinely built with Makefiles from the command line in a Linux environment (Red Hat Enterprise Linux 4).
The Makefiles point to the tools.
CCSv2.21 is NOT used to build the released applications routinely.

--
I was hoping to run CCSv2.21 on my Windows 7  64-bit PC. My attempt to install it failed.
I have not seen evidence on the E2E forums that anyone else has been successful either.
It appears that is not possible.

--
I was hoping to use CCSv3.3 with the old toolchain (DSP/BIOS+CSL, Code Gen Tools, DSPLIB) but it appears that is not possible, according to this post:

"Is it possible to build a C2000 project with cgtoolsv3.xx and BIOSv4.90.xx under CCS3.3?"
http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/p/31406/110241.aspx#110241

--
I converted the two VC5502 projects to CCSv3.3 projects.
The Project Updated (ID 5.1.8) automatically converted my DSP/BIOS 4.90 files (.cdb files) to DSP/BIOS 5.31 files (.tcf files).
I had to resolve a couple path problems to get tconf to work from the command line in our Linux environment.

I have been juggling tool versions.
Here is my current setup for the command line build in our Linux environment.

Compiler (Code Generation Tools) v3.3.6
DSP/BIOS 5.31.02
CSL: from DSP/BIOS 4.90.270 (this probably looks suspicious, but this configuration improved the behavior...)
DSPLIB: 2.20.02

The two applications build successfully from the Linux command line and in CCSv3.3 on a Windows 7 64-bit PC.

They begin to run on the two VC5502 DSPs when loaded from our normal startup process.
I have been focusing on one of the applications.
This particular application uses five tasks. For this discussion, let's call them:

TSK_4 (priority 4)
TSK_3 (priority 3)
TSK_2 (priority 2)
TSK_1 (priority 1)
TSK_idle (priority 0)

There are four software interrupt (SWI) routines. For this discussion, let's call them:

swi_4 (priority 4)
swi_3 (priority 3)
swi_2 (priority 2)
KNL_swi (priority 0)

There are a dozen hardware interrupt (HWI) handlers.
(I will spend time studying these more.)

HWI_INT18 - The interrupt service routine (ISR) for HWI_INT18 calls SWI_post(...) to trigger the swi_4 routine to run.

Debugging using CCSv3.3 and an XDS510 USB emulator, I observe the following:

a) Each of the tasks gets its turn to execute a few times right after startup.

b) After a few turns, the only things I see execute are the ISR for HWI_INT18 and the swi_4 function.
(The DSP/BIOS execution graph would have been useful here, but, alas, it is not supported for the C5000 family.)
I have not determined if the other tasks have stalled or if they are denied CPU time by the HWI_INT18 ISR and swi_4 function.