rom overflow?

[Gregwar]

Hello, The ROM size of the STM32 in the OpenCM9.04 is supposed to be 118000, but if I write firmwares biggest than ~57k, the IDE fails (region `rom' overflowed by 8 bytes)

[robotis-pandora]

Oh...Thank you for notice really important bug. you can modify rom(rx) length in flash.ld(@ core path you know) rom (rx) : ORIGIN = 0x08003000, LENGTH = 56K --> rom (rx) : ORIGIN = 0x08003000, LENGTH = 116K I will fix it at next version thank you.

[Gregwar]

Now the compilation step seems to work, but the flashing fails It looks like the bootloader fail writing the ROM, and the board have to be put in bootloader mode manually using the board button to recover it

[robotis-pandora]

Oops...right. you are right. below code is end of address in bootloader, sorry it have to be fixed as 0xF800 --> 0x1F800 gwEndAddressPointer = FLASH_START_ADDRESS + 0xF800;

Do you have ST-LINK or have you any experience using system bootloader in STM32?? It is needed to burn bootloader to OpenCM9.04.

[Gregwar]

BTW, Why isn't the bootloader open source? No problem for flashing, I can update my bootloader, but you have to fix the .bin file before

[robotis-pandora]

I updated bootloader in OpenCM repository. It compatible with CM-900 and OpenCM9.04.

[Gregwar]

The bootloader you've pushed is 128K, is it alright?

[Gregwar]

And it appear to say "-Ready.." instead of "Ready.."

[robotis-pandora]

Yes it is darwin Mini's total firmware including bootloader. Um.. so you failed again???

[Gregwar]

Yes And it seems that the Serial1 hardware bootloader is not responding

[Gregwar]

I eventually got my board working again, but I had to erase flash protection options Even the Serial1 bootloader was not working, is that normal?

[Gregwar]

Actually it's OK right, now, the hardware bootloader seems bricked but the bootloader works fine. (Be sure to also update the bootloader you put on commercial boards)

[Gregwar]

I've wrote a python script to send a program on the board: https://github.com/Gregwar/robotis-loader

[robotis-pandora]

Oh...goood... I can not use python script but i will try it. thank you. Yes, I updated new firmware again, please check if it wokrs okay.

[Gregwar]

Ok, it works OK but it's still preventing my Serial1 bootloader to write flash The python script is because we like using command-line tools. I think this it's a good thing having such a tool available.

[Gregwar]

It appear that you tweak the WRPR registers... is that necessary?

[robotis-pandora]

WRPR register means write protection to flash memory? Yes, it applied to only bootloader. Is there any inconvenience?

[Gregwar]

The problem is that Serial1 bootloader (that can be used with your port BOOT0 RX1 TX1 GND VCC) doesn't work with this enabled

[robotis-pandora]

you can modify write protection by using ST Flash Loader Demonstrator. http://www.st.com/st-web-ui/static/active/en/resource/technical/document/user_manual/CD00171488.pdf?s_searchtype=keyword

please let me know how to use Serial1 bootloader in your case.

[Gregwar]

Actually I am using stm32loader.py And you're right, there is indeed options to disable flash protection in it, I've tweaked it a little and it works

[robotis-pandora]

Ah...stm32loader.py :-) It is unfamiliar in Korea. python is also.

[Gregwar]

:-) So, OpenCM9.04 that are currently on the market do have the "57K bug" in their bootloader, right?

[robotis-pandora]

Yes right. I think some guide will be noticed. it was big mistake. Oh my... but, you are first man who reported it to me. Thank you very much :-) Almost 1,000 OpenCM9.04 was sold.

[Gregwar]

I have a solution: https://github.com/Gregwar/robotis-bootloader-fixer

This magical sketch will patch the bootloader, clients just have to load it and run it However, they may have to enter the bootloader manually the first time to re-bootstrap the board bootloading process

[robotis-pandora]

Wow Thank you. You are benefactor. I think about it how utilize what you made for ROBOTIS. Please let me know your e-mail address. Thank you again

[Gregwar]

My e-mail is: g.passault@gmail.com

[horchler]

So, this issue is still open? What's the current recommendation on solving it? I tried Gregwar's robotis-bootloader-fixer and that resulted in a pretty annoying bug – I have to perform a board reset before each upload. I tried Gregwar's robotis-loader python script after that and both of the OpenCM9.04 bootloaders here resulted in the same issue (and the script had to be control-C-ed). Perhaps there is also an issue with the new version of the ROBOTIS OpenCM9.04_1.0.2 IDE I'm using?

Also, if I wanted to revert my to the original bootloader/firmware, which version/file should I use?

[Gregwar]

Hello Actually, if you use my fix, you will have to go to bootloader manually for the first upload, but once you'll upload new valid rom you should be able to bootload your board automatically

[Gregwar]

robotis loader is intendeed to be used to send firmware just like OpenCM ide, this will not change your bootloader

[horchler]

@Gregwar: What do you mean by "go to bootloader manually for the first upload" (and "may have to enter the bootloader manually the first time to re-bootstrap the board boot loading process" in your earlier comment)? Is this something different from the instructions in your README?

[Gregwar]

Nope What I say is just that when you'll run the fixer, your board will have to be put in bootloader mode manually before sending your next sketch However, if you send a sketch that understand the signal to put the board in bootloader mode (which is the case if you use OpenCM ide for instance), you should be then able to send sketches as usually

[Gregwar]

Actually, the thing that make upload possible without manually putting the board in bootloader mode (holding the user button during reset) is some kind of backdoor in the virtual serial port that put the board in bootloader mode This is what is done here: https://github.com/robotis-pandora/ROBOTIS-OpenCM/blob/master/OpenCM_ide/processing-head/app/src/processing/app/Editor.java#L2612 https://github.com/robotis-pandora/ROBOTIS-OpenCM/blob/master/OpenCM_ide/processing-head/app/src/processing/app/Editor.java#L2724

And also in robotis-loader.py

[horchler]

@Gregwar: I am using the OpenCM IDE (downloaded from here). If I understand you correctly then the IDE should automatically be putting the board in bootloader mode every time I upload. I can send one sketch after going through the process in your README and then I get a "Board is not responding" error on all subsequent attempts.

[Gregwar]

Put the board in bootloader mode manually, holding the reset button during reset Then send any sketch from OpenCM IDE, like a blink or other example Then, you should be able to send sketches at any time

[Gregwar]

Can you get any sketch using the virtual serial port working?

[horchler]

I have to reset the board every time I want to upload a new sketch. After resetting I can load one sketch (these work perfectly including using SerialUSB) and then the next time I try to upload I get the "Board is not responding" error that I mentioned.

[Gregwar]

OK, let's try without OpenCM first, just download that example bin: http://gregwar.com/opencm/opencm904.bin

Try going to bootloader mode manually, and load that binary using robotis-loader.py If it works, try doing it again without putting the board manually in bootloader mode

[horchler]

Can you be explicit about what you mean by "going to bootloader mode manually"? Are there instructions for the OpenCM9.04? Is this different from the "Recovery Mode" described here?

Assuming it's the same as "Recovery Mode", if I hold down USER SW, plug in USB, and then release USER SW, I can load the opencm904.bin file (LOG 1 below). The green status LED starts blinking after a few seconds (sometimes it seems very random on how long it can take). However, once the status LED is blinking, I can't load the binary again – it stops at "Download signal transmitted, waiting..." until I press RESET on the board or control-C in the Terminal (see LOG 2 below). Maybe this is normal? I can load the binary again without having to unplug the USB if I either load it before the LED starts flashing or press RESET while it's flashing.

LOG 1:

mercurial:robotis-loader-master horchler$ python robotis-loader.py /dev/tty.usbmodem1411 opencm904.bin ~~ Robotis loader ~~

• Opening opencm904.bin, size=26332
• Resetting the board
• Connecting...
• Download signal transmitted, waiting...
• Board ready, sending data [ ################################################################# ]
• Checksum: 71
• Firmware was sent
• Success, running the code

LOG 2:

mercurial:robotis-loader-master horchler$ python robotis-loader.py /dev/tty.usbmodem1411 opencm904.bin ~~ Robotis loader ~~

• Opening opencm904.bin, size=26332
• Resetting the board
• Connecting...
• Download signal transmitted, waiting... Traceback (most recent call last): File "robotis-loader.py", line 65, in line = s.readline().strip() File "/Library/Python/2.7/site-packages/serial/serialposix.py", line 485, in read raise SerialException('read failed: %s' % (e,)) serial.serialutil.SerialException: read failed: [Errno 6] Device not configured

[Gregwar]

Indeed, I mean recovery mode

The behaviour of your board is not normal. Maybe this is related to Mac OSX, do you have any computer running on Ubuntu for instance?

[horchler]

I just tried on a colleague's Ubuntu (Linux Mint) machine. Very different behavior. Much worse. I was never able to load the binary. robots-loader.py aborted at various points, but always before sending the data.

Back on OS X – should I be able to load the binary again using robots-loader.py if the green status LED is flashing?

If it's helpful, I'm using Python 2.7 and PySerial 2.7 on OS X.

[Gregwar]

Did you disabled modem manager on your Ubuntu machine? By default, this service tries to use ttyACM* devices as modems