PDA

View Full Version : OpenCM9.04 IDE Problems



vehemens
12-05-2014, 06:06 AM
I've loaded the ROBOTIS OpenCM IDE (v1.02) onto a Windows 7 system which works except for downloading. The error message is "Board is not responding". The board shows up in device manager as a COM port when plugged in. The user button tricks mentioned in the RobotSource forum didn't help.

Not sure if it's driver, bootloader or some other problem.

Any suggestions would be appreciated.

tician
12-05-2014, 04:59 PM
How many times do you try to download? I had an issue some time ago where I would have to attempt downloading at least two times before it would succeed. It would give some sort of 'download failed' error the first time, then succeed the next.

vehemens
12-05-2014, 09:02 PM
How many times do you try to download? I had an issue some time ago where I would have to attempt downloading at least two times before it would succeed. It would give some sort of 'download failed' error the first time, then succeed the next.

Tried downloading multiple times as well as with two different boards. Each time it would report "Reset the board", "Compiling sketch...", "Transmitted download signal", then after a few seconds fail with the "Board is not responding" error message.

Tried RoboPlus 1.1.3.0 with Manager 1.0.33.0 and also could not load the controller software. Note that the instructions appear to be wrong as the green LED lit after plugging in the USB instead of before. Also after selecting find, it would ask for a power cycle, but as the manager status never changed in response, the only option was to cancel the attempt.

My Linux system USB driver reports the same information for both boards. Not sure how to determine the firmware version without a ST-LINK probe. One is a -B version purchased several months ago and the other is a -A purchased a couple of days ago.

tician
12-05-2014, 10:09 PM
I made a manual python firmware uploader for the various OpenCM boards that I had intended for use with Arduino-1.5.x (https://github.com/tician/opencm-1.5). It was going to be a major overhaul of the core to base it mostly on the Arduino 'sam' core in Arduino-1.5.x, but right now it is still the OpenCM core with a few requisite files to make it behave with Arduino-1.5.x instead of the OpenCM IDE. It has not changed much since creation almost a year ago because of continuing brain issues and lack of motivation to fix the Maple core (lots of horrible code and not being paid to fix it). The 'opencm.py' firmware uploader was based on the process used in the last available bootloader source code from the 'ROBOTIS_CM9_Series repository', so it may have changed to a closed source bootloader with the release of the Darwin-Mini.

jwatte
12-06-2014, 10:16 AM
I've found that sometimes the board changes port number. It happens typically if I crash the board while having the serial window open. Selecting the other port number in the IDE fixes that.
This is on Linux, although I'd expect a similar experience on windows.

vehemens
12-06-2014, 09:53 PM
I made a manual python firmware uploader for the various OpenCM boards that I had intended for use with Arduino-1.5.x (https://github.com/tician/opencm-1.5). It was going to be a major overhaul of the core to base it mostly on the Arduino 'sam' core in Arduino-1.5.x, but right now it is still the OpenCM core with a few requisite files to make it behave with Arduino-1.5.x instead of the OpenCM IDE. It has not changed much since creation almost a year ago because of continuing brain issues and lack of motivation to fix the Maple core (lots of horrible code and not being paid to fix it). The 'opencm.py' firmware uploader was based on the process used in the last available bootloader source code from the 'ROBOTIS_CM9_Series repository', so it may have changed to a closed source bootloader with the release of the Darwin-Mini.

Turns out I already had a copy of the code, so I'll take a look closer look at it. Ordered a ST-LINK probe last week so it should help with debugging.

The Windows driver shows up as Provider: ROBOTIS, Date: 4/25/13, and Version: 1.3.1.0. The driver binaries for OpenCM and ROBOPLUS are same (i.e. size and checksum).

vehemens
12-06-2014, 10:47 PM
I've found that sometimes the board changes port number. It happens typically if I crash the board while having the serial window open. Selecting the other port number in the IDE fixes that.
This is on Linux, although I'd expect a similar experience on windows.

Haven't seen a changing port number yet. Could you tell me which Linux distribution your using and what was needed to get OpenCM working on your system?

tician
12-06-2014, 10:52 PM
I've had a changing port number issue on xubuntu 12.04 and windows 7, but IIRC it was mostly due to messing with the cable or manually resetting the OpenCM while trying to download or use the SerialUSB window in the IDE (basically a fatal error of some sort that causes the OpenCM to re-enumerate while the old port number is still being claimed by some resource on the PC). Just changing the port used by the IDE to the new port number would allow it to continue functioning.

jwatte
12-07-2014, 02:05 AM
Haven't seen a changing port number yet. Could you tell me which Linux distribution your using and what was needed to get OpenCM working on your system?

I use Arch Linux, on a x86-64 machine. There exists a Linux executable. I installed the OpenJDK runtime, added some udev rules to make the OpenCM device writable by the regular user, and ran it. Works fine.
The 1.0.2 release even closes the serial monitor window when hitting "upload" for you, which is nice :-)

vehemens
12-07-2014, 12:57 PM
Managed to load the b_Blink_LED example using my FEDORA system after adding a udev rule and the ROBOTIS_OpenCM-v1.02-linux64 fileset with the lib/librxtxSerial.org and hardware/tools/arm/bin binaries replaced with links to my system ones.

The steps for downloading are convoluted and I still need to come up with something thats repeatable on my linux system and that works on my windows system.

I'm seeing the USB device number increment during the downloading process.

tician
12-07-2014, 01:41 PM
If there is a sketch running already, then the download process does require the OpenCM to do a watchdog reset into the bootloader (handled in the SerialUSB receive data callback), but I do not recall it causing any problems on the stock xubuntu 64-bit 12.04 or windows 7 systems. The OpenCM core/sketch and OpenCM bootloader do use different USB device definitions, so the device number may increment but the comm port should not unless there is a serious problem.

If you use the forced-startup-to-bootloader-for-programming (external pull-up resistor on CM-900; user-button on CM-904?) trick, then there should be no reboot or re-enumeration involved after the bootloader is entered. The watchdog reset and external pin state are both supposed to cause the board to remain in the bootloader indefinitely until it successfully programs its FLASH or receives some other command to enter TOSS mode, initiate another reset (non-watchdog), or start the sketch.

vehemens
12-07-2014, 10:19 PM
If there is a sketch running already, then the download process does require the OpenCM to do a watchdog reset into the bootloader (handled in the SerialUSB receive data callback), but I do not recall it causing any problems on the stock xubuntu 64-bit 12.04 or windows 7 systems. The OpenCM core/sketch and OpenCM bootloader do use different USB device definitions, so the device number may increment but the comm port should not unless there is a serious problem.

If you use the forced-startup-to-bootloader-for-programming (external pull-up resistor on CM-900; user-button on CM-904?) trick, then there should be no reboot or re-enumeration involved after the bootloader is entered. The watchdog reset and external pin state are both supposed to cause the board to remain in the bootloader indefinitely until it successfully programs its FLASH or receives some other command to enter TOSS mode, initiate another reset (non-watchdog), or start the sketch.

On my Linux system, once I have a program loaded and running the USB iManufacturer field is "ROBOTIS CO.,LTD.", and when in bootloader mode is "CM-900". Also a program can be consistently loaded once in bootloader mode as long as one gives the system and sketch enough time to remount the USB device after the reset.

However if I attempt to load a program via Windows, it appears to wipe out the program (i.e. LED no longer flashes) and Linux reports iManufacturer as "CM-900" for both program and bootloader mode.

vehemens
12-07-2014, 11:22 PM
However if I attempt to load a program via Windows, it appears to wipe out the program (i.e. LED no longer flashes) and Linux reports iManufacturer as "CM-900" for both program and bootloader mode.

Tracked the Windows 7 problem down to the "Renesas Electronics USB 3.0 Host Controller" driver. Once updated (per manufacturers recommendation) both OpenCm and RoboPlus Manager would load and run programs.

grober
01-21-2017, 07:01 PM
This is a rather old thread, but I hope it is still alive. I have the same problem when downloading any code to the OpenCM 9.04c board. I am using Ubuntu 14.04 32b. The device is correctly identified when I plug it in:
[65736.448298] cdc_acm 5-1:1.0: ttyACM1: USB ACM device
[65812.932306] usb 5-1: USB disconnect, device number 15
[65818.224104] usb 5-1: new full-speed USB device number 16 using uhci_hcd
[65818.390157] usb 5-1: New USB device found, idVendor=fff1, idProduct=ff48
[65818.390167] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[65818.390175] usb 5-1: Product: ROBOTIS Virtual COM Port
[65818.390181] usb 5-1: Manufacturer: CM-900
[65818.393281] cdc_acm 5-1:1.0: This device cannot do calls on its own. It is not a modem.
[65818.393333] cdc_acm 5-1:1.0: ttyACM0: USB ACM device
I added my user to the dialout group so that I don't need to change permissions (I tried changing permissions anyways).
Pressing the board button while connecting does not help.
The only way to do something is to boot my PC on Windows 7, press the board button when connecting, restore the firmware of the board using RPlus (it also takes some attempts until it recognizes the board and I can reset the initial configuration) and then download code to it (also requires several attempts). However, I would really like to download code from Linux/Ubuntu.
Any hint what could cause the problem? Maybe the configuration of the serial communication? The librxtxserial.so library?

Thanks

jwatte
01-22-2017, 08:20 PM
Note that switch from ttyACM1 to ttyACM0.
The way that the OpenCM changes devices when it goes into bootloader mode may race with the re-assignment of TTY device numbers, and thus you may need to re-specify a different device name.
If you want to work around that, try looking for specifics of the device, and writing udev rules that forces the name to something specific.

grober
01-23-2017, 02:26 AM
Thanks for your hint. However I already rejected that possibility by creating a udev rule and checking the existing ttyACMX ports.

I was playing around with the Python downloader by trician and found some interesting things:
- initially, the Python script was always hanging when changing into bootloader mode
- I outputted the response of the board and found the problem: even if the mode switch works, the response of the board to the 'AC' command is something like '-\nOK\r\n-', but with random characters missing, sometimes missing the O or the K.
- I circumvented that problem and a similar problem appears when sending 'AC&LD' (it should return 'READY' but always returns 'RADY') and at the end of the download (it should return 'SUCCESS' but I receive always ' SCCESS').
- I changed the expected return messages to these experimental values and everything works. Of course, I can only do this in tician's Python code, the opencm IDE expects the regular strings and therefore can't go on.

I tried changing the port properties, including timeout and bps, but the received messages are still weird (missing characters).

I will do some other experiments later. At least with this workaround I can download to the board using the Python script.

Any ideas?

tician
01-23-2017, 03:02 AM
If the script succeeds in pushing the firmware to the OpenCM (checksum matches and sketch works as expected) despite always producing the same faulty responses, then it is possible that the bootloader of the OpenCM has been slightly corrupted. Not sure how you are checking the responses, but if the response strings in the bootloader had characters erroneously replaced with NULL then it might appear to be a missing character when printed out. I do not recall the STM32 having any dedicated, write-protected memory for storing a bootloader, so possible it has been modified by a sketch storing data in FLASH or by the bootloader with a malformed binary upload (attempted a write to wrong address and modified itself).

The bootloader can be re-uploaded using the JTAG dongle sold in the Trossen Robotics shop for use with the Arbotix-Pro to push the bootloader file available in the OpenCM repository on github. Any other JTAG/SWD dongle should be able to upload the bootloader with OpenOCD, but I suspect only the STM dongle would actually work with the STM uploader program that is guaranteed to be able to upload the bootloader to the OpenCM.

grober
01-29-2017, 05:53 AM
That is the first strange thing: the faulty responses are only consistent for 'ready'->'rady' and 'success'->'sccess'. The faulty 'OK' response is misses random characters, sometimes is complete, sometimes is 'K', sometimes '- OK'...
Unfortunately I do not have a JTAG dongle. Is there any other way to restore the bootloader via USB? If STM32 doesn't have separate memories, couldn't I rewrite the bootloader through a sketch? Something like this: https://github.com/Gregwar/maple-bootloader-robotis (if I understand correctly what it does)?

grober
01-29-2017, 06:24 AM
Or like this? http://support.robotis.com/en/product/robotis_mini/darwin-mini_controler_firmware_upgrade.htm

Do I really need a special hardware? Am I mixing bootloader and firmware and they are completely different things? Can a compiled sketch be consider a firmware?

Sorry for the many questions, and thank you for your help!