Phantom_Phoenix on OpenCM 9.04...

[xenoc]

Ok I have the Serial3 on the Cm9.04 connected to an XBee and it's communicating with the other XBee connected to the PC. So I've got a wireless Serial Monitor working which is good. Not sure what the earlier problem was but it's working fine now.
What I would now like to know if I can upload Arduino sketches wirelessly over the other pair of Xbees I have connected.
Can I connect a usb cable to the USB port on the Cm9.04 and to the USB port on the XBee board and then upload programs over the XBee connection? Has anyone done this?

[KurtEck]

My gut tells me, that there may not be any way to update over XBees... I could be wrong... But my gut tells me that their bootloader is setup to work only from USB. Not sure exactly how they trigger it....

I have updated some microcontrollers like this that are connected to a robot that has another processor in the past wirelessly. That is I download the new hex file to the other processor (UP or RPI...) and then I use a command on that board to update the microcontroller.

Sometimes I issue a command line directly to do this. Sometimes if I want it automated, I have a script running on the RPI/UP that sees that a file changes and automatically does it and for awhile I had hacked up the Arduino IDE to add an option for download, which I setup to RCP to the remote machine...

Good luck

[xenoc]

Thanks for the suggestions. Doesn't sound easy though... I tried using a DFRobot Xbee USB adaptor with a Micro B to Micro B cable from that to the CM 9.04 USB but the upload won't work. I was hoping the Xbees could act as a USB extender but it doesn't look like it's a valid setup. I've heard that you may be able to use a BT 210 connected to the comms port on the 9.04 and do updates via Bluetooth. However that would tie up a UART that I need for the Commander and the serial monitor. So I might have to be content to continue wired programming via the USB.

[KurtEck]

My guess (as well as the answer up on Robotis forum) is that there may be special code that runs on the system that does a couple of things toward reprogramming the board.

First it needs to get the board into programming mode (some way to get to the bootloader).

Then the bootloader needs some form of handshaking, between the download program and the hardware. Not exactly sure what all it does here. But possibly(probably) includes the software then waiting for a USB device to show up that has some certain information in it's USB descriptor (Like vendor ID, Product ID). Which of course your XBee adapter (USB to serial) will not have, so the code will likely timeout.

If you got past that hurdle, then you might run into the next hurdle that the USB code may not use standard USB Serial protocol to download the code, maybe it uses RAW HID or some other... Again which the XBees don't know anything about.

As I mentioned in other response I was looking at different approach and that was to have small linux box on the Robot to handle this and other things. Right now I have UP board on one Robot, but on others may be RPI 3, but for real simple stuff, maybe an RPI0w.

There currently is still an issue running Arduino on Linux ARM for OpenCM boards: https://github.com/ROBOTIS-GIT/OpenCM9.04/issues/27

But my guess is that they use: DFU_UTIL for downloading....
So probably not hard to find/build a version of that utility for RPI, that could install the HEX file that you can send using WIFI to the RPI board and then use something like PuTTy window to reprogram your OpenCM board.

Update: Actually not sure if they use dfu util or not, that picture was for another board shown in the wiki. But if they did you could on the RPI install the dfu util program by: sudo apt-get dfu-util

So then would need to find sources for their uploader...

[xenoc]

Hi Kurt,
Thanks for all that info. I've had some success using a RPI 3 with Arduino 1.8.7 installed and the patch supplied by OpusK in your post to Robotis. As he said it's not reliable but after a few tries I've successfully uploaded the Phoenix OpenCM code and it seems to work ok.
So it's not ideal but usable. I've also heard its possible to upload code via bluetooth using a BT-210 adaptor. Have you tried this? I can't find any doco on it but my local robot supplier claims to have done it.
Regards,
John

[KurtEck]

Good to hear that it is at least partially working. Currently I am not working on that part of the code so have not tried it.

As for Bluetooth, I have not tried. But there might be some special bootloader mode that looks at some serial port... But again never tried.

Right now trying to make a new version of the OpenCM code work reliably, with some upgrades.

In particular I have SerialX.write(...) working where the writes don't block. That is currently on OpenCM, if you do something like:
Serial2.println("Hello World");

That call won't return until the complete string has been output over the serial port... My update makes it work like most other Arduino code bases and will put the data into a FIFO queue and return... With these changes need additional changes as for example make DXL buss work as you need to wait until the last part of a message is output before you change the IO pin controlling the direction of communications....

Working pretty good. But now also working to migrate the latest version of the Dynamixel SDK (different project) into the SDK code included in the Arduino builds, and fixing a few issues.

[xenoc]

I've got a RPI Zero W mounted on the Hexapod now and I can VNC into and upload an Arduino Sketch reasonably reliably (see below) The code works fine on the Hexapod once loaded but it takes several mins to compile the first time. So I was wondering if it's valid to use the opencm9.04_ld command shown below to upload a hex file compiled on my Windows server and copied to the PI. You mentioned DFU-Util elsewhere but it looks like Robotis use opencm9.04_ld to do the upload? Does that make sense to you? I'm a bit wary about experimenting too much in case I overwrite the bootloader which I believe is in flash.
I've also got the Pixy2 mounted and connected to the OpenCM 9.04 via the SPI1 interface and can see the object tracking data so making some progress there too.

Sketch uses 103560 bytes (88%) of program storage space. Maximum is 116736 bytes.
Global variables use 10728 bytes of dynamic memory.
/home/pi/.arduino15/packages/OpenCM904/tools/opencm_tools/0.0.2/linux/opencm9.04_ld /dev/ttyACM0 57600 /tmp/arduino_build_601453/Phantom_Phoenix_OpenCM.ino.bin 1 opencm
Enter bootloader
stm32ld ver 1.0.1
OpenCM Download Ver 1.0.4 2015.06.16
Board Name : CM-904
Ready To download
Flash : 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
Write Size : 103856


Flash OK
CheckSum : Success..
Go Application

[KurtEck]

Sounds good, yes they have their own download program. You should be able to build on pc copy down binary file and then use ...

i mostly use use my own fork with develop branch, which has several updates including serial objects not blocking on writes, some memory reductions...

info to on how to do this is up at https://community.robotsource.org/t/...equests/1474/7

[xenoc]

Thanks for the fork and the confirmation. I’m been able to download the hex file ok to the cm904. However I have a new issue. We included some Pixy code in Phoenix sketch. It compiles and downloads to the 904 ok but then the USB port disappears and I have to use the recovery button to restore it. So I’m assuming a run time error. Whats the best way of debugging this? I see that there is a development interface but that needs more hardware and I’m not sure it will help.
Thanks

[KurtEck]

Hard to say what is going on, especially without knowing additional information.

Things like how do you have your Pixy installed? Are you trying to talk to it, by Wire, SPI, or USART?

Have you tried running any of their (PIXY) examples? Is it working?

Note: If you are trying to use Wire, it is problematic, as their Wire library is trying to use a software emulation and not real I2C...

How to debug, without additional hardware. Try to figure out where it no longer works...

Note: Some of this may not work with current Arduino release of OpenCM... Not sure what parts have been released yet, but if you are setup to use the Develop branch as I mentioned above.

You start to sprinkle in Serial.print statements in all key locations in code. In particular at the start of Setup(), maybe after each main call out of setup, at the end of Setup... Note: sometimes a Serial.print("I am here"); may not output even if the Serial.print is called, if the calls after it crash... So when I start running into hard hangs like this, I do it like:
Serial.println("I got to here..."); Serial.flush();
The flush will make sure the write goes out before it continues...

Other things I do, include: If issue is with USB, and I have free hardware Serial port, I might rig up that Serial port to a USB to serial adapter (something like FTDI adapter) and change the outputs to that port...

Sometimes I try heartbeat LED, where I toggle LED and so can see if maybe the code gets to that first one...