TMS320VC5506PGE EBSR register issue

Basically EMIF port pins is reserved if GPIO is 0 at reset. Dynamic switching of the parallel port is not recommended. You should leave it as it and boot from I2C.

Regards.

Yes, the device is booting from I2C.

After bootup is complete, we need to write the EBSR register to change the /BKE bit as part of our initialization code. When we do this write, what value should we use in the Parallel Port Mode bits in order to avoid the switching warning that you mention?

I always use the logic "OR" or "AND" operand to change a bit in a register such to preserve the other bits.

Yes, this is what we currently have. The register reads back as 0x0203, so we end of writing 0x1203. Unless you mean that there is a mechanism of writing only the single bits?

Writing 0x1203 causes concern however as this is listed as a "reserved" value to have '11' in the parallel port mode bits. What Parallel Port Mode is the chip actually in at this time?

use bit manipulation to set the necessary bits within the EBSR...

bit_fld |= (1 << bit_index)

so in this case, EBSR |= (1<<12)...12 can be replaced by BKE or whatever macro there is to designate that BKE is associate with bit 12. I am not familiar with the header files of the processor in CCS.

The or-equal expression yields that same results as directly writing 0x1203.

We still need to know what Parallel Port Mode setting the device is actually in when powered up with GPIO0 = 0, since there is no definition of '11' listed in the datasheet (this is listed as "Reserved")

"Reserved" means the pins are not available for any known function. In this case, do not expect the EMIF function is avilable when GPIO is 0 at reset.

Regards.

EMIF functionality will not be a problem, as we want to use these pins as GPIO.A

Thus mode '00' is technically what we want, except for the "not recommended" comments above about changing it. Or is it fine to change it once, as part of our initialization?

The problem that we have observed occurs if we write the EBSR register (to change the BKE bit), and do *NOT* change the Parallel Port Mode bits (i.e. if we write '11' again as advised above). If we do this, then a serious error occurs on a few chips whereby we get some form of memory corruption.

As background, we manufacture several products based on the 5506 DSP. On a recent hardware build we found several manufacturing failures whereby the 5506 code would lockup if the PCB was inserted in the plastic housing. First thoughts were soldering defects of course, but this turned out not to be the case.

The problem was reproducible if flexing the PCB slightly in some cases, and eventually isolated to being consistently reproducible by just pressing lightly on the top of the 5506 DSP with a blunt plastic object. Several "good" and "bad" ICs were swapped between PCBs to confirm the rest of the circuit and soldering, and the behaviour followed the ICs in all cases, both good and bad. This then looked like perhaps a batch or quality problem with the ICs, until the discovery that it was software fixable.

Earlier this week, we found that the problem *only* occurs if we write the EBSR register. Specifically, it only occurs if we leave '11' in the Parallel Port Mode bits (i.e. do not change them). We have found that it is safe to write the EBSR register if we write '00' in the Parallel Port Mode bits.

So in summary:

• All is good if the EBSR register is not written at start-up.

• All is good if the EBSR register is written at start-up such that the Parallel Port Mode bits are changed to '00'.

• Failures will occur (but only on select ICs) if the EBSR register is written at start-up such that the Parallel Port Mode bits are NOT changed from '11'.

Note that the lockup failure does not occur when this line of code is executed, and the chip may run fine for hours. The failure can be easily triggered *anytime* later by light pressure to the top of the IC case (or other stress such as slightly flexing the PCB), but ONLY IF this line of code to write the EBSR register was executed back at startup time.

Thus we are looking for a much more detailed explanation as to why the IC boots into a documented "Reserved" mode in this usage scenario, and why changing this mode is documented simply as "not recommended" without further clarification.

Thank you for the detail description of issues. I have a few questions to further understand the issue.

Earlier this week, we found that the problem *only* occurs if we write the EBSR register. Specifically, it only occurs if we leave '11' in the Parallel Port Mode bits (i.e. do not change them). We have found that it is safe to write the EBSR register if we write '00' in the Parallel Port Mode bits.

Q: Since you boot from I2C, GPIO is 0 at reset thus Parallel Port Mode bits are "11" after reset without any write. Does problem exist on current build and previous build? Is this write occur in previous build which has no issue? Can you provide the symbolization of curent (fail) and previous (pass) devices? This can help tracking the fabrication data.

So in summary:

• All is good if the EBSR register is not written at start-up.

• All is good if the EBSR register is written at start-up such that the Parallel Port Mode bits are changed to '00'.

Q: When exactly is this write occur since I2C boot requires GPIO0=0?

• Failures will occur (but only on select ICs) if the EBSR register is written at start-up such that the Parallel Port Mode bits are NOT changed from '11'.

Note that the lockup failure does not occur when this line of code is executed, and the chip may run fine for hours. The failure can be easily triggered *anytime* later by light pressure to the top of the IC case (or other stress such as slightly flexing the PCB), but ONLY IF this line of code to write the EBSR register was executed back at startup time.

Thus we are looking for a much more detailed explanation as to why the IC boots into a documented "Reserved" mode in this usage scenario, and why changing this mode is documented simply as "not recommended" without further clarification.