Strange issue with Arduino Shield

Developers Control Chain
#1

Hi,

I’m working on a ControlChain device, using the Arduino Mega 2560 as a basis (more pins, memory, etc).

I have a small 1.8" TFT display from Adafruit. I’ve written some basic code to display some stuff on the display, haven’t yet started incorporating the CC stuff.

I find when I have the CC shield attached, and power it via the CC port, rather than USB, the arduino doesn’t seem to want to boot - the first line of my setup function sets the PWM to control the backlight of the display, and it is not even running that so it seems to me like setup() isn’t even called. The device is daisy chained off my MOD Footswitch. It’s not running out of current is it?

Thanks,

Guy.

#2

Hello Guy.

Does it work if you chain it off directly from the Duo instead of the MOD Footswitch?

#3

Hi Ricardo,

The behavior appears to be the same when connected directly to the MOD rather than chaining off the footswitch.

I have also tried completely disconnecting the display, and loading a modified version of the ‘Blink’ sketch to alternate a different pin high and low (the LED on pin 13 appeared to be stuck on when powered via CC), and measured that with my multimeter. When I power the Mega through USB I see the switching from ~0V to ~5.8V, when I power via the CC port I just get a constant ~1.4V (although the 5V locations on the board are showing a good ~5.9V).

So I then switched to an Uno that I had laying around. Running the same program on it (ie Blinking a digital pin) seems to be ok when powered via CC.

So, it seems to be quirk of using the Mega 2560 board and powering it through the CC shield.

Further thoughts much appreciated!

Thanks,

Guy.

#4

Ok, so here’s a strange development…

I did some googling and found this: https://www.arduino.cc/en/Guide/Troubleshooting#toc6

So apparently on some older arduino boards (Diecimilia) if you got junk on the RX pin during startup, the bootloader wouldn’t time out (Which is kinda what I figured was happening, because the Pin 13 LED was getting stuck on). So anyhow, if I connect RX to ground and plug into the CC cable, the board boots.

So, anyone got a bright idea as to how I can temporarily connect RX to ground until the device has booted, and then disconnect it from ground as the first line of the setup code? Are there transistors that have an open C-E path when there is no voltage applied to the base, and then closes of when the base is driven high?

#5

Alternatively can I modify the shield to use one of the other UARTs on the mega?

#6

A further development… connecting RX to 5V, or to TX (which was in the docs) seems to work as well. Seems like this is essentially a floating pin issue, so a pull-up or pull-down resistor should work. What is weird is that the shield is supposed to have a pull-up resistor on that pin (albeit to 3.3V not 5V) would that make a difference?

#7

Yes, that’s possible. But you will have to modify the library too.

There is already a pull-up resistor in the RX pin.

If you want to modify the shield the easiest solution is to connect the pin 3 of the IC (ISL83491) to an Arduino GPIO. That pin allows you to control the receiver. Now it’s grounded, which means always enabled by default. Once you have control of the pin, you can ground it via GPIO after the Arduino boot finishes. Note that you might also need to add a pull-up resistor from the IC pin 3 to the 3.3v.

#8

Thanks for the quick response!

To modify the shield would I have to disconnect the pin from its surface mount? I fear I’d do some damage.

I think, that since I’m a programmer and not a hardware engineer I’ll go for trying to modify the library to be capable of using one of the other UARTs (the Mega 2560 has 4 of them). That way all I have to do is clip the header pins and take new pins from those to spots on the shield to wires and into the appropriate sockets on the mega board.

Once I have it functioning I’ll work on a PR with you to incorporate it back into the library in a non-intrusive way. I assume that ReUART.h/cpp are where the magic happens?

#9

That is right. Actually, not to disconnect exactly, but you’ll need some tracks cutting and wire-ups.

Even though much easier than the previous one, here you also need to change the hardware by cutting off two tracks.

In the next hardware revision of the Control Chain shield, I’ll add a hardware fix for this issue. Thanks for reporting.

Yes, that’s the right place to look at.

#10

I have found that if you apply the soldering iron to the header pins, and pull with pliers from the other side, they tend to slide out of the black plastic seating quite nicely.

Yeah, perhaps bringing pins 3 and 4 of the IC out to pads that are easy to cut and/or re-solder would be useful.

A side benefit of using one of the other UARTs on the Mega is I can potentially use the USB serial to allow it to talk to a PC as well, which will be nice for debugging.

#11

Hi Ricardo,

I’m working on getting the library to work with the alternate UARTs on the Mega. My setup function seems to be crashing in cc.begin. More specifically, during the timer1_callback function in timer.cpp. It seems like g_callback is null. I’m not sure how that could be because it is passed in at core.c:344.

Do you have any thoughts why this would be?

Also, is it valid to run control chain code without the device actually connected to another control chain device (ie if it can’t connect to the bus it shouldn’t crash right)?

Thanks,

Guy.

#12

In the beginning of the timer.cpp file you can see that the Arduino timer library is added according the platform (#ifdef preprocessor). Make sure that the one needed for the Mega Arduino is also added.

Sorry, I didn’t get what you mean. Can you rephrase that?

#13

Thanks, I’ll double-check that. TimerOne is supposed to work with Mega, but perhaps there is a trick to it.

Right now, while I am testing the most basic library initialization, I am not actually plugged into the MOD, so there will be no signals on the wire. Is it ok to test like this, or should I always test my device connected to the end of a chain.

#14

That’s ok. You can even use it via USB (serial over USB) on your laptop for debugging purpose. In that case you would need to install the cc-master. Check the new section “Debugging your device” here: https://github.com/moddevices/cc-arduino-lib

#15

Hi Guy,

I’ve also run into the same issue with the Mega - have you made any progress in rewriting the library to use the other UART?

I’ve been contemplating getting a relay to disconnect the data pins on startup just to get me going…

Ian

#16

I’m still stuck with a weird issue with the TimerOne library. I don’t think it is actually the timer that is the problem, but a function pointer seems to be coming through as null

#17

So I managed to get past the issue I was having by changing the following in Timer.cpp:

void timer_init(void (*callback)(void))
{
    g_callback = callback; // moving this to the top seemed to prevent it from being null
    
#ifdef ARDUINO_ARCH_AVR
    Timer1.initialize();
#endif

    Timer1.attachInterrupt(timer1_callback);
    Timer1.stop();
    
}

My MOD doesn’t seem to see the board when plugged in. @ricardocrudo what would be the best way for me to show you my modification to ReUART.cpp to see if I did anything obivously wrong in supporting UART1? Shall I paste here? Or on a github issue?

I will also check with an Uno board to make sure that I didn’t damage the IC on the shield when I modified the TX/RX pins.

Thanks,

Guy.

#18

Thanks for the update Guy.

#19

Make a fork of the project on the GitHub and send me the link of your clone.

#20

My controller is working quite nicely now apart from this power issue (have been using a separate power supply so far).

I need to use it next week for an event so for the time being will explore the route of using a little relay to connect RX to TX while it’s booting (crude I know but don’t see why it shouldn’t work) - is there a page showing the control chain pinouts?

Thanks