Hi guys,

I'm developing an application using the AT91SAM7X as a USB->JTAG/UART/SPI/GPIO general purpose device. I have no operating system, and have based the code on the SAM7X-EK USB-CDC example, and the USB-CDC-MSD example

On the host system I'm using libusb-1.0 and pyusb-1.0, on both windows and linux (of many flavours)

I'm compiling the at91sam7x firmware on linux using gcc-4.5.0 and binutils 2.20.1.20100303

I have the following problem:

The application works fine and is stable most of the time, however, when I place the USB cable next to a power plug, and plug/unplug that device (i.e. generating ESD spikes), the USB connection drops, and I cannot re-connect until I have done a power-cycle of the AT91SAM7X part.
I'm using this in an industrial environment, so require it to work when placed next to a switching source (plugging/unplugging devices is just my testcase). I've tried shielding cables, etc, etc, but no improvement.

This is consistant on windows and linux on many different machines, so I do not believe it is the host _hardware_. it happens on all boards and when running on an Olimex EVK also.

I have tied the TST and JTAGSEL pins to ground, with no improvement (I use the Erase pin, and suspect that this is not the problem, as the firmware seems to be fine when I reboot the part).

I currently do not have access to the JTAG debug tools to check what is going on in the CPU, but my attempts to write Exception debug routines have not yielded any information.

So, the questions that I have are this:
1. How to check if I'm getting caught in an exception handler (preferably using USB)
1a. Are there any standard exception handlers that someone can point me to? And any way of recovering from an exception (I'm just learning assembler at the moment)
2. Why doesn't pressing the reset button allow me to re-connect?
3. Has anyone else seen something similar.
4. Is there any other debugging steps I should be taking?
4a. Is there any other information that would be useful to prove to this forum?
4b. Are there any better forums to post to?

Hi,

For detail explanation and to locate exact cause you need to share the schematic, especially USB connection part. I have worked with LCP2148 to develop USB device application around 3 yrs before. So I am little bit familiar with USB.
See, there can be two types of USB devices.
1) Bus powered: Can be powered up from USB interface only. Ex USB Pen drive. So Power On/Off automatically executed after insert/removal of the device.
2) Self powered: Can be powered from USB or External power source. Ex USB CD-Writer with external adapter. So Power on/off cycle won't be there against insertion/removal of the USB cable. So some mechanism is required to detect the cable removal.

I suppose you already aware with the USB enumeration, Full speed, Half speed modes. Just by connecting 1.5K pull up resister to D+/D- line, device get configured for full speed/half speed accordingly. Here the trouble begins.
I feel you are using full speed configuration. In bus powered system you can connect the 1.5K pull up resister permantly to the D+ line. Until this resister is present on the bus, Host will consider that something is arrived on USB bus and starts communication. Once enumerated then the device went in some other state (depends upon type and usage). At this stage if you reset the MCU(Not expected in bus powered), enumeration just can't happen because host is not aware of this situation. So when you remove the power and again connect back, the pull up resister temporarily goes off which notify the host that device is no more present on bus. So host resets its state back to "Start". So after power up the pull up register aging comes in picture and host start communication from scratch. So everything goes well in Bus powered system.
Whereas in self powered system, the MCU has to take care of connecting/disconnecting the pull up resister on D+ line. So you can use PNP transistor to switch this 1.5K pull up resister on/off. I'm not aware with Atmel USB MCUs, Some MCU manufacturer give internal pull resisters configurable for ON/OFF through some SFR. So check what is available with your MCU. In self powered system, after power up the MCU initializes all peripherals including USB engine (pull up is not active) and after completion of some necessary task it waits for USB insertion. After USB cable insertion the power coming from USB cable (First pin of the connector) can be used to sense the insertion (generally known as VBUS pin), which generates interrupt to MCU (can be also polling based). In ISR the 1.5K resister is made on by making PNP transistor on or by setting bit in some SFR. This notifies the host the arrival of device on bus starts enumeration. Again after removal of cable MCU has to take care of making off the pull up resister using PNP transistor or SFR bit.
Hope this explanation is enough for your problem. I had same problem with USB device so I feel this explanation will help you. please reply once you resolved the problem may by some other means.

Regards,
Prashant

Hi,
some month ago I worked with such an chip using USB. At this time there were some while-loops inside the Atmel USB stack. Some of the loops contain no loop timeout.
Plugging/ Unplugging of the device sometime results in never setting/ clearing such an bit and the loop runs forever. Only a power cycle resolve this problem. I am not sure if such loops still exists.

Workaround:
- loop timeout or watchdog

Best regards,
Edi

Thanks,

So where I stand now is this.

1. Shielded USB Cables make a big difference. I _can_ generate a glitch with a shielded USB cable, but I have to make a real effort. That's my current solution and I'll work with this for now.

2. The Pullup resistor is _not_ controllable on chip (and I didn't put a pmos on my PCB), so for now I must do a cable disconnect and re-connect to issue the enumeration. I would love to make this transparent, so for the next spin of the PCB I'll put some detection etc on board.

3. The default Exception handlers in the Atmel code are infinite loops. I've changed them, but I'm still a bit lost in the world of assembly as to what I need to do to clear the Exception, and return to my code. If I have a way of disconnecting the in-cable resistor I'd like to reset the device and handle the disconnect/reconnect in the application, but I can't because of 2.

4. In my earlier experiments I was using the watchdog, but couldn't get it to work... probably again due to 2.

5. Exception handlers - a followup question:
All the documentation I see seems to imply that I need to write assembly for these handlers. Does anyone have some assembly code that clears the flags and returns to the main loop? Can this be done using plain old C?

Thanks for the input so far.
I've got enough to get me going for now, and I'll let people know when I get time to progress further.