Dagu Mini Driver not responding

[japonophile]

Hello,

I bought the Raspberry Pi camera robot and got it working fine.

Last week, I got some ultrasonic sensor and wanted to try it, but since it is a 4 pin sensor (HC-SR04), I thought I'd try to modify the Mini Driver firmware to use different pin for Trig and Echo. (I realize now that my plan to use pin D13 for Echo might not be a good idea since D13 is the pin to drive the built-in LED, but I haven't got that far anyway).

I then tried to upload my modified firmware and it started fine, but stopped at the end of the flashing process:

Code: Select all

Python 2.7.3 (default, Mar 18 2014, 05:13:23)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import mini_driver
>>> m = mini_driver.MiniDriver()
>>> m.connect()

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9307
avrdude: reading input file "/home/pi/.ino_uploader/mini_driver_firmware/.build/atmega8/firmware.hex"
avrdude: writing flash (7642 bytes):

Writing | ################################################   | 95% 6.02savrdude: stk500_recv(): programmer is not responding
False


I tried again running the avrdude command manually, but it consistently fails with the following error:

Code: Select all

$ avrdude -p atmega8 -P /dev/ttyUSB0 -c arduino -b 9600 -D -U flash:w:firmware.hex:i -v -v -v -v

avrdude: Version 5.11.1, compiled on May 23 2012 at 11:08:25
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "/etc/avrdude.conf"
         User configuration file is "/home/pi/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/ttyUSB0
         Using Programmer              : arduino
         Overriding Baud Rate          : 9600
avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding

avrdude done.  Thank you.


I came to think that my bootloader may be corrupted.
Is there a way to check whether it is the case?
Or could it be that my Mini Driver is "broken"? (the red LED is lit)

Assuming this is the case, I did some research and found it is possible to reburn the bootloader (http://letsmakerobots.com/node/35649), but I do not have another Arduino at hand.

I saw it may be possible to reburn the bootloader using Raspberry Pi:
viewtopic.php?f=5&t=1362&p=1778&hilit=bootloader&sid=f82f1407f11a17ad239898db1b03ffee#p1778

If applicable, could you explain how to wire the Mini Driver to the Pi to perform this operation?

Thanks,
Antoine

PS: The RasPi Camera Robot is a lot of fun

[japonophile]

OK, for reburning the bootloader, I found the following tool & (great) explanation:
https://bitbucket.org/DawnRobotics/pi_isp

I should be able to try that, but I'd be interested to know how to further diagnose the problem and whether bootloader corruption is really the issue. (I'm hoping I did not somehow burn the Mini Driver...)

[Alan]

Hi Antoine,

Glad to hear you're back up and running. It sounds like the bootloader was corrupted, but I'm not sure why this happens occasionally. Possible causes I've looked at in the past are corruption due to low power/brownout, or perhaps self corruption due to some unidentified bug in the bootloader, but I haven't been able to recreate the bug reliably. I have some ideas I'm working on for a long term fix but for now I'm just helping customers to reflash their mini drivers if a corruption happens.

I wouldn't worry about damaging the mini driver just by trying to upload a new sketch. The main things to avoid are the things here.

Regards

Alan

[japonophile]

Hi Alan,

Thanks again for your quick reply!
I will try re-burning the bootloader.

-Antoine

[japonophile]

Hi Alan,

Thanks for your support.
Waow, this is getting epic!

I have opted for flashing the bootloader of my Mini Driver through another Arduino (Nano), instead of from the Pi, as I was afraid to break the pi due to the different voltage.

But this turned out to be very complex.
Here are a few issues I faced (and solved):

- The Arduino Nano I got was actually a Chinese clone with chip CH340, and the serial USB was not visible even though I installed the FTDI drivers (on Mac OS X). To solve this, I referred to the following post and the ZIP driver mentioned there worked for me. http://kiguino.moos.io/2014/12/31/how-to-use-arduino-nano-mini-pro-with-CH340G-on-mac-osx-yosemite.html

- After flashing the Arduino as ISP to the Nano, I could not flash the bootloader to the target (Mini Driver) using Arduino IDE. It kept throwing the following errors:

Code: Select all

avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x15
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x15
avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x14
avrdude: stk500_disable(): unknown response=0x12

The solution I found was rather non-trivial: it involved running the avrdude command through gdb, so I could stop the program while the target is resetting, and resume it when reset is complete.
The procedure is described here: http://notes.asd.me.uk/2011/10/20/using-the-arduino-uno-as-an-avr-isp/
Here are the commands that worked for me:

Code: Select all

$ gdb -args avrdude_bin -C ../etc/avrdude.conf -c arduino -p m8 -P /dev/cu.wchusbserialfd120 -b 19200 -e -u -U lock:w:0x3F:m -U hfuse:w:0xca:m -U lfuse:w:0xdf:m
$ gdb -args avrdude_bin -C ../etc/avrdude.conf -c avrisp -p m8 -P /dev/cu.wchusbserialfd120 -v -b 19200 -U flash:w:/Applications/Arduino.app/Contents/Java/hardware/arduino/avr/bootloaders/atmega8/ATmegaBOOT-prod-firmware-2009-11-07.hex -U lock:w:0x0F:m

And for each of them, I put a breakpoint in stk500_getsync.

Now, my Mini Driver seems back on track. Yahoooo!

However, as I am trying to flash my modified firmware, I get a verification error.

Code: Select all

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x1c00
         0xdd != 0x12
avrdude: verification error; content mismatch

But when I revert the original driver, the flashing is successful.
Question: is it possible that my firmware is getting too big? If so, how can I detect it?

The reason I am asking is because flashing my modified firmware says:

Code: Select all

avrdude: writing flash (7642 bytes)

However, I saw the following line in boards.txt, suggesting I am over the max code limit:

Code: Select all

upload.maximum_size=7168

Advice greatly appreciated.

Thanks,
Antoine

[Alan]

Wow Antoine, that does sound fairly epic.

The error you're seeing, could indeed be due to there not being enough memory on the Mini Driver. It may be possible to use avrdude to read the data in memory back from the mini driver so you could use that to confirm whether this is the problem.

In order to get around the memory problem there are a couple of options I can think of

• Reducing the size of your sketch - sorry for stating the painfully obvious - perhaps there are features I implemented you can do without?
• It's possible using an ISP and the Arduino IDE to write a sketch that wipes out the bootloader first and uses its space so that you've got more room for your sketch. I think that there are 8192 bytes in total on the Atmega8 so this should give you enough space.
• Finally, getting a bit desparate but you may be able to hack bits out of the Arduino libraries so that they take up less space. I know that the mini_driver_firmware.ino sketch doesn't fit into memory with newer versions of the IDE because the size of the Arduino libraries has bloated, so perhaps it's possible to go the other way.

Hopefully, one of the above will be useful to you. Depending on what you're planning to do with the sketch in the future, we also now sell the Mini Driver MkII which uses an Atmega328 instead of an Atmega8 and so gives a luxurious 32kb of memory. I think it's fairly reasonably priced, but this is probably diminished somewhat by the fact that you're all the way over in Japan.

Regards

Alan

[japonophile]

Thanks a lot for the advice!
Well, trying to slim out the sketch is also kinda fun.

But as you mentioned atmega238, I was thinking the Nano v3 (clone) I got does actually have 32K. Would that be a possible replacement for the Mini Driver? Well, I guess no, since I think it does not have the PWM pins for controlling the motors, right?

[Alan]

Hi Antoine,

The nano will be able to produce PWM signals. The thing that it lacks is the motor driver (the arrangement of transistors on the mini driver) to drive the motors. However, you can disconnect the motor driver from the mini driver by removing the 4 jumpers (the yellow block marked D9, D7 etc in the manual) and instead connecting the relevant pins to the Nano.

You'll probably also need to use a breadboard so that you can wire the servos to the Nano. I doubt all of this will be pretty, but it should work.

Regards

Alan

[japonophile]

Hi Alan,

I see. So (just to make sure I understand), if I'd want to use the Nano + the motor driver of the Mini Driver, I'd load my sketch onto the Nano, and connect all my sensors to it. Then I'd remove the jumpers on the Mini Driver, and I'd connect 4 output pins of the Nano directly onto D7, D8, D9, D10 of the Mini Driver. And I'd connect my left and right motors as usual to the ML and MR pins of the Mini Driver. Correct?
Would I need to power the Mini Driver in this case, or would the motor driver get the power from the 4 input signals?

I'm still looking how to reduce my sketch size so I could go with the Mini Driver, but just to understand your proposed solution.

Thanks,
Antoine

[Alan]

Hi Antoine,

That's correct. Some batteries would need to be connected to the +/- connector on the Mini Driver as that is what is fed through to the motors, but you could probably get away with just using 4xAA batteries (assuming that you're powering the Pi with a powerbank here). Then you'd need to connect the GNDs of the boards together so that voltages are relative to a common ground, but electrically that should be all you need to do.

With regards to the software, there may be a few issues with writing the PWM signal to the motor driver on the Nano (Atmega328). Essentially, to control the motor speed you would normally just use analogWrite to set the duty cycle of a PWM signal coming out of a pin attached to the motor driver. On the mini driver board though, I couldn't use the analogWrite function on a number of key pins, due to the fact that I also use the Servo library (on the Atmega8 there's a conflict). I got around this by setting up a timer, and bitbanging out the PWM signals using an interrupt (the function down at the bottom of the code). The settings for the timer may work on the Atmega328, or you may have to have a look at the Atmega328 datasheet to modify it slightly. Alternatively you might be better just ripping that stuff out and using the analogWrite routine.

Regards

Alan