Trouble with some pins on an A-Star 32U4 Mini LV

Support A-Star and Orangutan
1

Hello!

After somehow burning up/shortening my first Mini LV attempting this, I’ve ordered a new set of components to start fresh, and made sure that the wiring is proper this time around. My goal is to have 1 board with an IR receiver, which then drives 4 pairs of motors using 2 DRV8835 dual carriers (each driver output goes to 2 motors, which should roughly turn at the same time/rate). The problem is that some pins (5/4?) do not seem to work. The pinout that I have planned for this is as follows:

PIN Function
0 = Status LED OUT
1 = IR Receiver IN
2 = Carrier 1, Input B, Phase OUT
3 ~ Carrier 1, Input B, Enable OUT
4 = Carrier 1, Input A, Phase OUT
5 ~ Carrier 1, Input A, Enable OUT
6 ~ Carrier 2, Input A, Enable OUT
7 = Carrier 2, Input A, Phase OUT
8 = Carrier 2, Input B, Phase OUT
9 ~ Carrier 2, Input B, Enable OUT

Each driver has mode and logic VCC connected to the A-Star’s 5V output. The motor side is connected to the battery pack, which also feeds BAT+ and BAT- for the controller itself.

The problems are:

  • Carrier 1, Motor A does not seem to work at all, so at least setting pin 5~ does not seem to work. Not sure if the phase/direction pin 4= works as a result.
  • Carrier 2, Motor A only goes in one direction, so I assume that setting pin 7= does not seem to work - faulty soldering, this works now!

I’m a software person, so I’d like to apologize if this comes across as very amateurish (because it probably is!). Is the usage of pins 5(/4) limited somehow? Do I need to do something special to access them (i.e. more special than just pinMode(5, OUTPUT)/analogWrite(5, 200)? Besides the pins listed above, I don’t really have any utility that I need, i.e. no special need for other pins. It’s really just a stupid GPIO/PWM project to control a truck trailer’s crane. So if I would need to e.g. call/set something to free those pins up, that should probably be doable.

I did notice - but am not sure about it - that when I set pins 4/5 on the board it sometimes seems to freeze/go into an undefined state of some kind (until the next powercycle) - is that related somehow? At least, it seems to ignore IR commands, but the timer-based logic continues as usual.

I’m using the standard bootloader, Arduino IDE, and the Pololu board type. It detects the board properly, and the other pins/motors work as expected (i.e. carrier 1B using pins 2/3 is OK; as is carrier 2 with 6/7/8/9).

I’ve set the pins in an array so I can easily switch between them using the IR. Skipping the IR and general state handling, this is how I’m accessing the pins/drivers:

int8_t selectedMotor = -1;
int8_t direction = 0;
uint8_t motorPWMs[] =  /*~*/ { 3, 5, 6, 9 }; // [AB]ENBL
uint8_t motorModes[] = /*=*/ { 2, 4, 7, 8 }; // [AB]PHASE
#define MOTOR_COUNT 4

void initPins() {
  for (int i = 0; i < MOTOR_COUNT; ++i) {
    pinMode(motorModes[i], OUTPUT);
    pinMode(motorPWMs[i], OUTPUT);
  }
}

void selectMotor(int8_t newIndex) {
  if (selectedMotor != -1) {
    analogWrite(motorPWMs[selectedMotor], 0);
    digitalWrite(motorModes[selectedMotor], LOW);
  }
  selectedMotor = newIndex;
  analogWrite(motorPWMs[selectedMotor], 0);
  digitalWrite(motorModes[selectedMotor], LOW);
}

void setDirection(int8_t newDirection) {
  if (selectedMotor == -1 || direction == newDirection)
    return;

  analogWrite(motorPWMs[selectedMotor], 0);
  digitalWrite(motorModes[selectedMotor], newDirection > 0 ? HIGH : LOW);
  if (newDirection != 0)
    analogWrite(motorPWMs[selectedMotor], 200);
  direction = newDirection;
}

Thank you in advance!

Edit: Re-checked the soldering, and pin 7 wasn’t soldered properly on the driver side, hence the pin was okay, but the connection to the chip wasn’t. Fixed that, but the issue with 4/5 remains.

2

Hello.

You shouldn’t need to do anything special to use analogWrite() with pin 5. If it is easy to do so, could you try swapping your two DRV8835 carriers and see if the problem stays with pin 6 or follows the motor channel? Alternatively, you could try swapping the input signals for channel A and channel B on your DRV8835 carrier 1.

Could you post more information about the rest of your setup (i.e. what power supply and IR receiver you’re using), as well as a copy of the simplest, but complete program that demonstrates the problem? Also, could you post some pictures of your setup that show all of the connections as well as some close-up pictures of the A-Star and problematic DRV8835 carrier?

Brandon

3

Hello Brandon,

while compiling the documents I think I’ve found the source of my troubles - at least partially:

So it seems like pin 5 doubles as a timer for the IR receiver - so when I analogWrite it, that seems to disable/kill the timer, causing the IR to stop receive commands (and therefore be perceived as “dead” - quick Serial.println() confirmed that the Star was still happily loop()-ing, just that IR wasn’t processed anymore).

I followed the guide to the IRTimer.hpp (Timer and pin usage), which led me to the #define-s for this bit:

One #define IR_USE_AVR_TIMER4_HS later and I can use C1A - but now C2A isn’t working anymore (pins 6~ / 7=). I’ve swapped the two DRV around (the construct I’m building has headers for both chip and the base plate, so swapping things around isn’t hard to do), the result is the same. Removing the #define and it’s the other way around again (C1A unresponsive/killing IR, C2A working fine).

So steps that I’ve taken:

  • With #define IR_USE_AVR_TIMER4_HS (to move the timer to pin 13), C1A (4= / 5~) works, but C2A (6~ / 7=) stops working
  • Without the #define, C2A works, and C1A doesn’t (in addition to killing the IR receive loop somehow)

So I think it’s not a hardware problem, as I can somewhat successfully toggle between either carrier output working depending on an #define.

I’ve swapped IRRemote.hpp for TinyReceiver.hpp and after disabling the parity check (not sure why - I suppose the IR remote that I bought from you guys doesn’t do that?), it seems to work like I’d expect it to. I didn’t get the parity issues back when I was still using the IRRemote.hpp itself - not sure what is causing that, but I think it’s negligible for my use case.

This whole hardware business is rather confusing to be honest - I’m not quite comfortable with the concept of “It’s a configurable output, or input, but sometimes it has sometimes magic side effects too” :slight_smile: I can understand the concept of “You can use this pin, but then <other functionality> is no longer available on the board itself” - but I’m not quite sure why moving that from 5 to 13 then causes 6/7 to… quit. I guess the reason why the motor didn’t run on 5 was because the IR library used it as a timer and so no voltage was really emitted?

Thank you for your help!

4

On the ATmega32U4 (which is the microcontroller used on the A-Star 32U4 Mini boards), Timer 3 is used for pin 5 and Timer 4 is used for pin 6, so that explains the conflicts you are seeing. You can refer to this pinout diagram on the A-Star 32U4 Mini LV product page for more details.

You might consider going back to using Timer 3 for the IR receiver and making sure to use the pins controlled by the other timers (Timer 0/1/4) for your driver signals (i.e. pins 3, 6, 9, 10, 11, and 13).

Brandon

1 Like
5

I’ve looked at the pinout for a lot longer than I’m comfortable to admit - but as someone without any experience in reading these kind of things, it wasn’t clear that these pins have a special meaning. The way I read it was that it’s a PWM output (OC4A, negated?) and capable of analogWrite (OC3A). I thought it was a bit odd, but had kind of assumed it was just some internal naming (e.g. from the ATmega32U4) that was exposed for those in the know. Looking at this page I think I understand what you (and the pinout) means now. As a software developer that usually several layers away from anything hardware-y, it’s still a bit spooky to have… uh, what I’d call “outputs with side effects by design”. A bit hard to wrap my head around it, but I’ll just accept it as a thing that happens and try to pay more attention in the future.

Ignoring the disabled parity check, it seems to work fine with just TinyIRReceiver, which doesn’t require a HW timer. As the logic I’m using is rather simple anyway, I think I’ll be fine using that instead - there’s not really a need to use a HW timer or precision for this project. I’ve shuffled the code around a bit so the remote usage is less fragile in case it does decode the signal wrong once in a while, but so far, it all seems to work fine without issues. Fingers crossed, I guess!

Thank you again for your help!

6

Hello,

It sounds like you probably have the right idea now, but just to clarify: the light gray boxes indicate all of the PWM outputs of the ATmega32U4, while the blue text in those boxes indicate the PWM outputs that can be used with Arduino’s analogWrite function, so those are the ones you should focus on here. (The black text indicates alternative timer outputs that can be configured on a given pin, but the Arduino environment does not make use of them.)

Kevin