Serial Communication Appears Unsuccessful

[ksteiner1234]

Hello, Thank you for your project on github! I've been able to flash the arduino project to my board (with boot0 and boot1 set to 0), but am having issues getting the 8x8x8 LED executable to communicate with my LED cube. I have the buad rate set to 2,000,000 and see the little Tx light blink on my programmer when I send a packet. But the cube doesn't update. I've set the boot0 and boot1 switches to 1 following the project download. I have gotten to step 13 in the readme, but I'm not sure how to verify serial communication is functional.

[Sliicy]

Hi @ksteiner1234! When you power up the cube to 5V, do all the lights light up? And also, when clicking on the Start, Cycle Mode, or Next buttons, does anything happen on the cube? Start/Pause should make all the LEDs light up white, Cycle Mode should make a bluish-green pattern, and Next should shut off all the LEDs (and reset restarts the board). If the cube reacts to these actions, then it is running the firmware. If not, it hasn't been flashed.

Follow-up question: Have you checked under Device Manager on Windows to verify that there aren't any unknown devices attached, and that there is just one COM Port detected?

[ksteiner1234]

Yes, I get the behavior you describe: all white lights after flashing the board. And then alternating blue/green panels when pressing the Cycle Mode. The LEDs shut off when clicking Next. Reset sets them all white again.

My device manager shows what you describe only mine is COM3: "USB-SERIAL CH340 (COM3)"

[Sliicy]

Awesome, so the cube is correctly flashed, and your computer sees the cube.

Can you try opening the program, heading to Settings, and ensuring you have the same settings as in this screenshot? COM Port can be any number (3 in your case). But try using a baud rate of 38400. And make sure to press 'Connect' last.

[ksteiner1234]

I have tried several baud rates (I don't recall all of them, but I did try both 2,000,000 and 38,400). When I click connect, I do not get any error and the "Connect" button changes to "Disconnect". But I do not see any change in the LEDs (They are all currently off - after pressing "reset" with Boot0 and Boot1 both set to 1).

Quick question, should the cube command under "Send Packet" update based on the selected "Send Color"? If I'm understanding the "Cube" syntax, the packet should set the LEDs to all red (?).

[Sliicy]

So actually, when connecting, the cube won't do anything different the moment it connects. But to test that its properly connected, you can click Send Packet to send the color red to test it:

Or you can go to the first tab, and open any app, and try out a game. And the LEDs may stay off when pressing reset. But they should light up once a packet is sent to it.

[Sliicy]

I should probably change the behavior so that when connecting, the cube should light up whenever connected.

[ksteiner1234]

When I hit "Send", nothing happens to the cube LEDs. Similarly with any option I've tried from the Menu. I see a little Tx light flicker on the programmer (I assume indicating that a command has been sent). But the cube LEDs remain off.

[Sliicy]

Can you verify that there aren't any other apps open that might also have a handle on the COM Port? The truth is, any Serial Port communicator should be able to communicate to the cube (I even tested this once using Serial USB Terminal on Android). If you send the following 2 packets (one at a time) from any Serial communicator, it should tell the cube to turn red: Packet #1: 0x00, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF,

Packet #2: 0x00, 0xFF, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF,

Also, the cube doesn't send any responses back to the host. The communication is currently one-way, for speed improvement. Could you also try swapping the Tx and Rx probes, just to test if that might be why?

[ksteiner1234]

I sent packets #1 and #2 via Tera Term for 4 cases: 2 baud rates (38400 and 2000000) with 2 Rx/Tx wire configurations (what I used when I flashed the code and the opposite configuration). I could see the programmer Tx light illuminate when I sent the packets. As expected, the programmer light illuminates longer with the lower baud rate than with the higher.

Do you have a serial loopback function perhaps from your initial troubleshooting you could provide? I could drop that in to make sure the data is getting read into the receivedBytes array.

[ksteiner1234]

also, I reset the board before each of the 4 cases.

[Sliicy]

I didn't create any loopback functions. I'm still trying to come up with a solution.

[Sliicy]

Can you attach photos of the board and switches on the yellow mini board?

[ksteiner1234]

So I was actually just able to get it working after some messing around a bit. I'll try to write up some more details when I get the chance (may be this weekend) with the specific steps I've walked through as well as some of the things I don't quite understand. Having to head to bed now, but wanted to let you know real quick since I just saw you responded here.

Thanks again!

[Sliicy]

@ksteiner1234 I will close this issue for now, but whenever you have a chance, I'd love to incorporate the steps you took to resolving this issue. Feel free to add it here. Thanks.

[ksteiner1234]

Ok, finally getting around to this.

So a few things I've stumbled through:

1. When I go to load the arduino image, my switch configuration needs to be BOOT0 -> 1 and BOOT1 -> 0.

The other states (below) yield the following error:

• BOOT0 -> 1 and BOOT1 -> 1
• BOOT0 -> 0 and BOOT1 -> 0
• BOOT0 -> 0 and BOOT1 -> 1
  • "Error: Activating device: KO. Please, verify the boot mode configuration and check the serial port configuration. Reset your device then try again..."

I had managed to figure this out before I reached out to you.

Switching BOOT0 to 0 and pressing either reset allows the program to run. I seem to get the same behavior regardless of the state of the BOOT1 switch.

2. I didn't initially have an appreciation for the distinction between the communication packets being sent as hex values versus ASCII values. So when I initially tried to send the packets you listed, I had inadvertently sent the ASCII codes for each character in the packet rather than the bits specified by the hex values. I was ultimately able to successfully send the packets after I converted them to hex files (using a hex editor) and sent them as binary files through TeraTerm.

3. I noticed the RGB arduino image had the baud rate set to 38,400 rather than 2,000,000 (as listed in step 4 of the 'How to Run'). I still do not know why things didn't initially work when I changed the baud rate to 38,400 in your executable, as you recommended. Perhaps the switches were in the wrong configuration and I didn't realize it at the time. Still a little puzzled by that...

As a side note, I've been unable to get the comms to work with any baud rate other than 38,400. I've tried most standard speeds from 38,400 to 2,000,000 (adjusting the argument in Serial1.begin initialization command). Still a little puzzled on that, but I've been able to get things working and haven't pursued it since.

I think that's the gist of it - let me know if you have any follow up questions. Thanks for making this available. I reached out to the CubeSmart email regarding the issues I was having with their software. Turns out, I had found the monochrome version. They said they don't have an English version of their software for the RGB 8x8x8 cube, which kind of perturbed me a bit. I've been able to write a Matlab script in which I can generate my own animations through the com port and command them to the arduino image you've provided (in addition to using your applet).

Thanks! Kyle