Post 25: Initial Hurdles with BeagleBone Black
BeagleBone Black is a God Sent for Embedded Developers. It provides unique features which were unthinkable a few years back.
Imagine 1 GHz processing, and one feels that embedded developers who were like very happy at even 72 MHz went in a tizzy!
You can find a lot more about BBB (as I prefer to call the BeagleBone Black). The authentic source will always be Beagleboard.org, but as with everything Open, the information abounds and your ability to Google determines if you can find it.
And this ability, or rather lack of MY ability is the subject of this post.
Well we had a BBB setup which essentially is controlling a Slave controller via Serial Port.
Now, know this, I know as much about Linux, as Newton knew about Theory of Relativity. Which means zero. Oh OK!, not zero but very close to it!
So, as mentioned above we were controlling a slave controller (MSP430) using BBB. Initially we were able to receive data from the controller on UART0 (or known as TTYO0 in the linux file system)
Many attempts of Transmission of data from BBB to MSP430 were leading us to dead ends. I looked and re-looked at the serial code but to no avail.
Looking at the help on various forums, I decided to power it with external power supply. Then without any modifications to the code the serial communication was established and the entire master slave interface ran beautifully.
So far, So good!
This system was for an Australian customer, so we packed up and sent the system to them.
This is how it looked. As you can see, we had hooked three wires from J1 (J1.1,J1.4,J1.5) to a connector on our PCB. Before dispatch the circuit was running continuously for extended period of time, without any issues.
So a couple of days later, my customer received the PCB, switched it on in this precise configuration. Opened the software in Cloud9 IDE, as we were at our end, and tries to run it in manual mode. Only 1 transaction went through, then nothing! And by nothing I mean, after 1 transaction there was no successful transactions, inspite of power cycles, hard resets and what not!
We tried different exe’s with different timeout delays, but no success.
So we decided to debug this by connecting the BBB to the PC via TTL-232 converter. Which looked like this:
For serial debugging, we used the tool XCTU from Digi, our favorite tool for serial debugging. (Try it out!)
This problem persisted for multiple days and nothing happened. What we were seeing was that garbled data appeared after transmission of the master frame. Sometimes, the BBB also used to reset.
We were doing communication at 9600 baud and thus we decided to try different baud rates to view this data.
Then suddenly at baud of 115200 the data made sense. It was being sent by BBB and had details about user name and password. There was a lot of stuff there but unfortunately, I have not saved the image of the same.
Further scavenging of the Internet, I came to know that ttyO0 is the default debug port! If you are interested you can find further details here.
So with this information, I started on the trail to find how to disable this. Finally I found my answer on one of the Google Groups. Link to that group is here. In there look for the answer by guy/girl with user name as jgold.
The answer is that you have to run the command systemctl mask [email protected] to disable the default debug port. The system ran perfectly at my end as well at my customer end.
Now you may ask me how did it run at my end and did not run at my customer end, INITIALLY. Well, honestly, I am at loss here! If you know the answer please educate me!
Thanks!