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
Has invited:

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
void
systemreset(bool to_bootloader)
{
if (to_bootloader) {
      stm32_pwr_enablebkp();
      /* XXX wow, this is evil - write a magic number into backup register zero */
      *(uint32_t *)0x40002850 = 0xb007b007;
}
up_systemreset();
/* lock up here */
while (true);
}


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

USB.jpg

if(usb_inited == 0)
{
GPIO_InitTypeDef   gpio;
//This is a trick to perform a USB re-enumerate
***********
GPIO_SetBits(GPIOB, GPIO_Pin_12 );
vTaskDelay(500 / portTICK_RATE_MS);
GPIO_ResetBits(GPIOB, GPIO_Pin_12 );
}



case PROTO_BL_UPLOAD:
if (cin_wait(usb_vcp_timeout) != PROTO_EOC)
      goto cmd_bad;
sync_response();
vTaskDelay( 200 / portTICK_RATE_MS );
GPIO_SetBits(GPIOB,GPIO_Pin_12);
vTaskDelay( 500 / portTICK_RATE_MS );
GPIO_ResetBits(GPIOB,GPIO_Pin_12);
__DSB();   /* Ensure all outstanding memory accesses included
                      buffered write are completed before reset */

SCB->AIRCR   = ((0x5FA << SCB_AIRCR_VECTKEY_Pos)           |
                        (SCB->AIRCR & SCB_AIRCR_PRIGROUP_Msk) |
                        SCB_AIRCR_SYSRESETREQ_Msk);                                     /* Keep priority group unchanged */
__DSB();                                                                                                         /* Ensure completion of memory access */
while(1);  
break;


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:
#NOTE: 2015/8/26 14:26:53 Comments : 
Alarm_Font_Size,2
Alarm_GPS_Status_Enable,1
Alarm_H_Alignment,1
Alarm_H_Position,180
Alarm_Low_Batt,20
Alarm_Low_Batt_Enable,1
Alarm_Over_Alt,1000
Alarm_Over_Alt_Enable,0
Alarm_Over_Speed,100
Alarm_Over_Speed_Enable,0


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 = 2

BTW 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:


...

To reply to a question, please Login or registered