PlayaUav OSD bootloader
Hi,
Firrsty testing with the preloaded firmware, everything worked OK and got OSD.
I did a build of the master branch and uploaded it to address 0x8004000 using the JTAG port.
Uploaded OK, but didnt get OSD starting. After that I tried it at 0x8000000 which probably means I overwrote the bootloader.
So is the bootloader firmware available to upload somewhere?
EDIT:
To ease development of PlayUAV OSD on Linux I have written a command line PlayUAVOSD Firmware upload tool for Linux.
The source is on Github
----------------------------------------------------------
WARNING. I wouldnt advise doing the following unless you know what you are doing. If in doubt use the official OSDTool
If you are feeling brave you can try running the binary on i386 system running linux. Use the view raw button to download it. Please report any success or failure you have with the tool
-----------------------------------------------------------
It requires the bootloader to be loaded
Usage is simple, where firmware.bin is the firmware in .bin format
PlayuavOSD-util -write firmware.bin
Now works whether the board is running the OSD app or in bootloader
If you build, It has one dependency on my quan library also on my github repository
regards
Andy
To reply to a question, please Login or registered
17 replies
Tom - PlayUAV
Favor from:
Hi Andy,
The firmware does start from 0x8004000(See line #142 of src/system_stm32f4xx.c)
I guess sector 11, which is used to store setting parameters, has been erased, so there is no output on the screen. You should set the display parameters using the config tool.
The codes of PlayuavOSD BL are based on px4 BL. You can get it at OSDBL.
The codes are a little messy and out-dated. I will rewrite it with the latest PX4 BL and put at github.
Regards,
Tom
Tom - PlayUAV
Favor from:
Hi Andy,
FYI, I just put the codes of bl at github. Because there are design differences between the playuavosd board and the px4 FMUv2 board, I made a standalone branch "playuavOSD" instead of merging it with the master code.
https://github.com/rentt/Bootl ... avOSD
PX4 used the RTC register to keep a magic number before jumping to the bl, which need a battery on the board. This design aims to solve the USB re-enumerate issue. See the PX4 firmware Firmware/src/modules/systemlib/systemlib.c
Playuav OSD board did the same "evil" thing. Instead of using a battery, we used a transistor to connect a GPIO pin with the USB_DP. Setting the pin high-level for a while will simulate a USB re-enumerate. See osdconfig.c
The other difference is that playauvosd bootloader won't erase sector 11 because it is used for parameters.
Regards,
Tom
andy
Favor from:
Hi Tom,
I built the bootloader OK and managed to get eveything working again using the OSDConfig tool in Windows. Thanks for providing the bootlaoder code repository.
I would like to get things working in Linux, so I can use that as my dev plataform Unfortunately I'm not having much luck with that at the moment. The Linux version of ST--Link isnt allowing me to have control over sections I will have a think about it and, if necessary will work in Windows on the video telemetry
regards
Andy
andy
Favor from:
My current solution to uploading to PlaytUAVOSD in Linux.
PlayUAV Linux Upload Hack
Its currently pretty raw stuff. No command line args or anything, so the usb port name and firmware file are hard wired in. It uses the .bin file rather than .hex as that appears to be the bootloader's upload format. No crc checking yet . Requesting the Flash size causes a hang for some reason...
EDIT: requesting flash size now working and crc working
Reenumeration simply by opening the next available port on reset to bootloader after re-enumeration
Anyway tested on a couple of Blinky apps and the current OSD firmware and seems to work.
regards
Andy
Tom - PlayUAV
Favor from:
Hi Andy,
Great! It is really useful for the Linux guys. This reminds me that I should put the OSD setting in xml files instead of the hard-code. Or I could write a cross-platform GUI config tool with QT. I am not good at QT, but with QGC as my reference, it should work.
Regards,
Tom
andy
Favor from:
I tried building the OSDTool in Linux using Mono. It failed to build but I dont think it wouldnt need much work to get it running in Linux, however, a problem with C# is that C# requires a fast PC, which is why I didnt pursue it. My cheap netbooks used to hang regularly when I used the old Mission Planner ( I believe the OS couldnt keep up with data requests from my memory starved netbook when running Mono), so I ended up using the command line to set EEPROM parameters on the APM. The newer APM planner is done in C++ in QT I think, so they must have recognised this issue. ( My little command line uploader utility also runs Fast, maybe 5 seconds to invoke it, upload the new firmware and reboot the OSD :) )
It would be great having a language neutral file format for storing parameters. My little tool could easily be modified to read some config files too
As to config file format, xml is good for a machine to read, but I wonder if there is also some benefit to keeping it simple and human readable and writable?
For example a file to upload flash vars to my OSD
.. so I hope you consider alternatives to XML too such as YAML or even TOML or just value = expression pairs :)
Anyway whatever you choose, I will try to support it with my little utility :)
regards
Andy
Tom - PlayUAV
Favor from:
Hi Andy,
Currently the config tool can save the parameters as a text file with the file menu. The codes are from MissionPlanner. The parameter files look like this:
Though I am also not happy with the codes of config tool, they don't bother the users(Windows). So I think it is not urgent to modify the config tool now. I will rewrite it sometime in the future.
Regards,
Tom
andy
Favor from:
I meant to reply to this before. For me the above text file format works very well as a way to specify parameters. It is easy to parse by an application and easy to modify by hand too
regards
Andy
andy
Favor from:
There is one issue, which is that in some European countries the comma is used a decimal point so maybe an alternative separator between name and value could be allowed as well?
regards
Andy
Tom - PlayUAV
Favor from:
Hi Andy,
Glad to see it works on Linux. About the separator, it does an issue in Config Tool(windows). Which separator do you suggest?
Regards,
Tom
andy
Favor from:
How about '=' ?
NOTE: 2015/8/26 14:26:53 Comments :
Alarm_Font_Size = 2BTW then a parameters file is a valid Python source file which may or may not be useful in practise!
regards
Andy
Tom - PlayUAV
Favor from:
I have changed the separator symbol from ',' to '='. Prerelease branch.
A warning will pop up when loading the old format settings file. The user needs to replace the separator manually.
Regards,
Tom
maciek_252 - FPV and open source fan
Favor from:
Hi,
I'm the next one who have tried to compile and load the code using stm32flash, and the board stopped working. I tried to compile the bootloader and the hack published above, but it does not work out of the box. There is a problem with the quan library, should I compile it separately?
The binary of the hack tool from the link above is missing.
Could you please write which commands should I execute to restore the bootloader from linux?
EDIT: I've managed to build the tool and upload the bootloader and the firmware compiled by me. I'm happy but I still do not understand completely what goes on here. Do we use the same command for uploading the bootloader and firmware?
./playuavosd-util -fw_w playuavosd_bl.bin
./playuavosd-util -fw_w PlayuavOSD.bin
Doest the util recognize what is its argument?
mkschreder
Favor from:
If the boot0 pin was available then we could just be using the built in bootloader in rom and things would be sooo much simpler. It's kindof frustrating not being able to use the standard way of flashing stm32s.
mkschreder
Favor from:
I was able to load the code using built in bootloader by cutting the trace between boot0 and ground, bringing boot1 to ground, connecting boot0 to vcc, powering on the board into boot mode, flash using stm32flash to address 0x0 then disconnect boot pins from vcc and ground and reboot. Also I had to change the system_stm32f40x.c to use interrupt vector at 0x0 instead of 0x4000. Works great. No chance of ever bricking the board since the stm32 bootloader is in rom.
mkschreder
Favor from:
...
mkschreder
Favor from:
...