Timeout while waiting for Wixel to reconnect

Hi David,

Thanks for getting back to me… I sent my order information to the support email address.

Your comment about the hazard of driving P2_2 low has me confused. If you recall I had asked if there is any danger in driving the Yellow LED high and low. Your response is that it should not be a concern. But the Yellow LED is tied to P2_2 is it not? So If I drive the Yellow LED low, am I not driving P2_2 low also?

And lastly… Do you think this situstion could be caused by static discharge? Are the Wixels easily affected by static electricity maybe?

Tim

Here is my original comment about P2_2:

To elaborate on that comment: If the user happens to short P2_2 to 3.3V while your app is driving P2_2 low, that will cause a short circuit because you are connecting a low output directly to the 3.3V regulator. That is why it is preferable to never drive P2_2 low, but it is fine to drive it high or make it be an input. What was your code doing with the P2_2 line?

Most of the electronics we sell, including the Wixel, are easily affected by static electricity because all the parts on the board are exposed. A static shock could certainly damage the Wixel.

–David

Hi David,

I understand what you mean by it being a hazard to drive P2_2 low, then have the user connect the 3.3V jumper, and how that would create a short circuit. Thanks for that…

Let me try and explain why I keep talking about the Yellow LED…

If we connect 3.3V to P2_2 the Yellow LED lights up. So I’m assuming that the Yellow LED and P2_2 are the same circuit… When we set the Yellow Led = LOW, is P2_2 also being set to Low? In other words… If we set the yellow LED = low, and then connect the 3.3V jumper to P2_2, would we be creating a short circuit?

My confusion is not about setting P2_2 low… It’s about understanding if P2_2 will go Low IF I set the Yellow LED low… Are they connected at the hip?

Hope this makes sense…

Tim

Hello, Tim.

The LED_YELLOW macro from the Wixel SDK is defined in board.h:

/*! Turns the yellow LED on if the argument is non-zero, otherwise
 * turns it off. */
#define LED_YELLOW(v)       {((v) ? (P2DIR |= 0x04) : (P2DIR &= ~0x04));}

It never drives the line low; it only changes whether the line is an input or an output driving high.

–David

I do not really understand the code… But I understand what you are saying… So if it is defined as an input, the led will be Off, or On?

How would you re-write this code safely…

void setPins(uint8 XDATA * buf, uint8 byteCount)
{
    uint8 byte, pin;

    // loop over all bytes in packet
    for (byte = 0; byte < byteCount; byte++)
    {
        for (pin = 0; pin < outPinCount; pin++)
        {
            // check if this output pin's link matches the link in this packet
            if ((uint8)pinLink(outPins[pin]) == ((buf[byte] >> PIN_LINK_OFFSET) & PIN_LINK_MASK))
            {

            	static BIT bVal = ((buf[byte] >> PIN_VAL_OFFSET) ^ 1);

            	// Only allow one pin to be powered at a time
            	if(outPins[pin]==10 && isPinHigh(11)){bVal = 0;}
            	if(outPins[pin]==11 && isPinHigh(10)){bVal = 0;}

            	setDigitalOutput(outPins[pin], bVal);

            }
        }
    }
}

It would be off because the I/O pin would not be supplying any current.

There is nothing unsafe about that code, unless you were to configure P2_2 to be an output in the configuration settings of the app in the Wixel Configuration Utility. So I would just recommend that you avoid doing that.

–David

David,

Despite writing quite a bit of code, I’ve not succeeded in wiping out the bootloader flash so far, which seems to be what may have happened here to these folks. I do understand that application code is not supposed to be able to affect the flash boot loader area, but for arguments sake lest just assume it can happen somehow. So what tools, software and/hardware would be required to re-flash the boot loader? Surely The chip manufacturer must have some procedure. Unless it is proprietary, or requires circuit variations not possible with the MCU soldered to the board, it would be worth a try, no?

Hello. That would not be feasible because the bootloader is proprietary and we do not give it out.

If you have your own tools for programming a CC2511, there is nothing on the board that prevents you from using the Debug Interface (documented in section 11 of the CC2511 datasheet) for programming. Unfortunately, I don’t know of any good, cheap programmers for the CC2511.

–David