Windows ST-Link can't use pre-built ELF

[mungewell]

The pre-built elf (stm32f3_HID_for_real.elf) can not be used in Windows ST-Link utility, it only accepts bin, hex, s19 and srec.

Any chance of one of these (pre-built) to save new users having to install the full tool kit and build their own?

[mungewell]

I managed to figure out how to covert the elf using 'objcopy' in a Linux VM. $ sudo apt-get install binutils-arm-linux-gnueabi $ /usr/bin/arm-linux-gnueabi-objcopy -O ihex stm32f3_HID_for_real.elf stm32f3_HID_for_real.hex

The result can be found here: https://dl.dropboxusercontent.com/u/34518077/stm32f3_HID_for_real.hex

Loaded up via ST-Link in Windows 7 and board now shows up as a 'Tracker DK' in Hardware Manager. Looking forward to some Oculus testing....

Cheers, Simon.

PS. ST-Link download was here: http://www.st.com/web/en/catalog/tools/PF258167 http://www.st.com/web/en/catalog/tools/PF258168

I also found a Linux/GitHub equivalent but have not tried it yet. https://github.com/texane/stlink

[michael-betz]

Hi mungewell,

Very cool, thanks for the hint about the .hex file. I included it now on GitHub.

I have never tested building (and flashing) the project on windows, so I totally forgot about the .hex file.

What do you think about putting a short step by step guide together, explaining how to flash the .hex file under windows. We could share that on the GitHub project page.

Cheers YFL

2014-05-07 22:10 GMT+02:00 mungewell notifications@github.com:

I managed to figure out how to covert the elf using 'objcopy' in a Linux VM.

$ sudo apt-get install binutils-arm-linux-gnueabi $ /usr/bin/arm-linux-gnueabi-objcopy -O ihex stm32f3_HID_for_real.elf stm32f3_HID_for_real.hex

The result can be found here: https://dl.dropboxusercontent.com/u/34518077/stm32f3_HID_for_real.hex

Loaded up via ST-Link in Windows 7 and board now shows up as a 'Tracker DK' in Hardware Manager. Looking for to some Oculus testing....

Cheers, Simon.

PS. ST-Link download was here: http://www.st.com/web/en/catalog/tools/PF258167 http://www.st.com/web/en/catalog/tools/PF258168

I also found a Linux/GitHub equivalent but have not tried it yet. https://github.com/texane/stlink

— Reply to this email directly or view it on GitHubhttps://github.com/yetifrisstlama/Foculus_Rift_Tracker_STM32F3DISCOVERY/issues/1#issuecomment-42476918 .

[mungewell]

Got the SDK built on Linux and the Foculus lets it run the sample apps. https://sourceforge.net/apps/trac/speed-dreams/attachment/ticket/822/Foculus_World.jpg

Seems to be something wrong with the scaling of the sensors though.... I think that the gyros are under reporting (ie. scaled too low).

[michael-betz]

Hi Mungewell,

that's quite interesting. I used to have some problems with the sensor scaling in the earlier versions of my code.

There was this funny effect in the Oculus World demo, where the camera points in the right direction only after the STM board was held very still for a while and after the slow correction from the accelerometer sensor kicks in.

However, in the current version, I thought I had understood the scaling and solved that problem. In fact, there are several scaling factors defined in peripherals.h, which are used to convert from the raw sensor readings to units of [10^-4 rad/s]. They were derived from the sensitivity as quoted in the datasheet of the gyroscope sensor (L3GD20). This did the trick for me and the gyroscope scale fit perfectly in the Oculus World Demo and in several Windows Apps.

So I'm actually not quite sure where the problem could be. However I would be interested in reproducing it. Could you tell me exactly how you compiled and tested it.

Cheers, Michael

2014-05-08 6:43 GMT+02:00 mungewell notifications@github.com:

Got the SDK built on Linux and the Foculus lets it run the sample apps.

https://sourceforge.net/apps/trac/speed-dreams/attachment/ticket/822/Foculus_World.jpg

Seems to be something wrong with the scaling of the sensors though.... I think that the gyros are under reporting (ie. scaled too low).

— Reply to this email directly or view it on GitHubhttps://github.com/yetifrisstlama/Foculus_Rift_Tracker_STM32F3DISCOVERY/issues/1#issuecomment-42512930 .

[mungewell]

It got the SDK here: https://github.com/jherico/OculusSDK

Which might be out of date (or simply wrong). I'll have to sign up, and download from official sources I guess. Will try this later...

The 'SensorBox' application is the best way to see the problem. With the STM32 board flat on a table the accelerometers will not change, by turning it (yaw) by 90' should show the same on screen done only with gyros. I am seeing about 1/2 the expected rotation.

Within the 'World' application, from facing forward turn the board to look at floor. On screen would only look down by around 45' and then slowly creep the reset (Sensor fusions correcting itself from accelerometers I guess). Pressing 'r' instantly corrects to looking straight down.

Note: I did not compile the Foculus code, just flashed the hex into the board. Is copy of GitHub out of date?

[mungewell]

I checked on a Windows machine and the tracking seemed correct in OculusWorld (0.2.5c and 0.3.1) and also with the Helix roller-coaster demo (which over-stress my PC).

Your might also get a kick out of this, which stems from the '25c I2C adapter': https://sourceforge.net/apps/trac/speed-dreams/attachment/ticket/822/smallest_rift.jpg

Technique here: https://dl.dropboxusercontent.com/u/34518077/70c_rift.txt https://dl.dropboxusercontent.com/u/34518077/FoculusEDID3.sh

[michael-betz]

Very cool EDID emulator ;) I applied a similar hack so my DIY HMD gets recognized as an Oculus Rift.

About the scaling problem. I didn't manage to compile the open source SDK from jherico yet but will keep trying when I have some time. Meanwhile, you could try something which might help to narrow down the problem. Try to change the SensorBox application, so that it requests a different sensor scale. In theory this shouldn't change the behaviour at all, as the SDK is supposed to manage the rescaling accordingly. But let's see what happens ...

The relevant code is on line 199 in the file SensorBoxTest.cpp: if (pSensor) pSensor->SetRange(SensorRange(4 * 9.81f, 8 * Math::Pi, 1.0f), true);

Cheers YFL

[mungewell]

Will give the range stuff a go on Tuesday.

For others wanting to build a similar cable, remember to check that there is a pin 9 in the connector (I have seen some without). The wiring is as follows: Pin 5 (0v, Gnd) = Black Pin 9 (+5V) = Yellow Pin 12 (Data) - Orange Pin 15 (Clock) = Purple

[mungewell]

Just reporting back on the alternative st-link. https://github.com/texane/stlink

I was able to use this (with arm-gdb) to program a Discovery board with the firmware. Usefull if you don't want to download the whole development enviroment.

I have opened a ticket specifically for the gyro issue.