Sensor Mezzanine + Atmel-ICE


#1

Hi,

I’m building a project on the Sensor Mezzanine and I’d like to do some in-depth debugging. As I understand it this is modeled after the Arduino Uno which typically requires you do some simple modding in order to enable the debugWire feature of the Atmel chip. I understand the Mezzanine uses the DB’s RTS line as reset, but this seems to be impeding the enabling of debugWire (which uses the 328P’s reset), even though I’ve separated the parts and am powering the Mezzanine externally. Is there a similar modification that needs to be made on the Sensor Mezzanine? My goal is to use the Atmel-ICE to leverage Atmel Studio 7.


#2

Hard to tell…

The best thing to do is compare the schemtic of the Uno with the schematic of the sensors board: https://github.com/96boards/96boards-sensors/blob/master/Sensors.pdf

Looks to me like the DB’s RTS line is routed through a transistor so the baseboard should not interfere with the reset line when reset is not asserted. However I’m not sure if the capacitor on the reset line could interfere with debugwire. Have you got links for the Uno schematic and proposed Uno mods?


#3

Yes! See here: https://www.arduino.cc/en/uploads/Main/arduino-uno-schematic.pdf

In this design it’s the net just to the right of C5 (RESET-EN). In the layout there is a pair of pads (http://atroshin.ru/sites/default/files/arduinouno_reset_en.jpg) with a trace shorting them that you can cut. This disables bootloader functionality since the FTDI chip can’t reset the 328 anymore, but now the ICE can use RESET like it wants to.


#4

The reset circuit for the 96boards sensor mezz is completely different to that of the Uno and there is no breakable link to help you. I think you would have to depopulate the components that interfere with the reset line if you want to debug using debugwire.

As a warning, everything I know about board design I learned by osmosis. In other words I know enough to experiment on cheap boards but don’t have the proper theoretic understanding of what I am doing. In this particular case I’m not sure what C3/R7 are for although I suspect they might be required to make the transistor do its thing properly. So with a disclaimer that if you break the board that’s your problem rather than mine :wink: then if I was trying to make debugwire work I would depopulate C3 and test, then D1 and test, then Q1 and test. At that point debugwire really should work (since the we almost completely aligned with a modded Uno at that point) so if it doesn’t I’d assume I damaged the board somehow whilst trying to depopulate…

If someone else confidently suggests something else then its OK to assume I overlooked something…


#5

I’m thinking that D1/R2 is also worth a look.

D1 from 5v via 1k R2 resistor in parallel with 10k pull-up at R1, which means a lot more current that the debug interface will have to sink compared to the arduino design (10k). Is the debug interface capable of sinking >5 mA?

C3/R7 are just to keep reset stable. Its a low pass filter. Its just there to keep high frequencies from freaking out the atmega.

Note that removal of D1 or R2 (pick one or the other, whichever is the easiest) will have NO side-effects, except obviously that D1 won’t light up any more. So that would be the first thing I would try.


#6

Agree.

The reasons I recommend the particular ordering for component removal was:

  1. C3/R7 will probably mess up the debugwire edges… so remove C3 first.
  2. Current consumed by reset light could cause problems… so remove D1.
  3. Transistor is now the only difference between a (modded) Uno and the
    (modded by 1. and 2. above) sensor board… so remove Q1 if it still
    doesn’t work.