CLOAD details

[poizone]

I'm looking into porting cleanflight to our little quads. The hardware is almost an exact match to the NAZE build target, with the differences being the GPIO pin assignments. That's the easy part at this point.

On the other hand, I'm wondering what the major steps in building the .bin file to be flashed over the radio are. I've checked the differences in the makefiles, but I'm not well versed in them at all. It looks like I'll have to integrate our CLOAD argument functionality into the cleanflight makefile, but the lines that I need aren't so clear, nor how to use them in the build process. Which bits should I be looking at to port, what are the required inputs for the CLOAD script, and how should I be calling them?

[arnaud]

Hi,

To flash the CF2 STM32 the command is as follow:

Code: Select all

./cfloader flash cflie.bin stm32-fw

cfloader is part of the crazyflie-clients-python project.

[poizone]

That's one step past what I'm looking for. The cleanflight build outputs a .hex and a .elf file that is flashed over a wired connection, whereas the CF firmware build has another step that generates the .bin used to flash over the crazyradio. I'm looking for the details on how the .bin is generated at compile time so I can modify the cleanflight build process to generate a crazyradio flashable .bin in addition to the .hex and .elf.

Also, this is being built for the CF1, not the CF2.

[arnaud]

The bootloader is flashed at the begining of the flash so the difference between a firmware built for flashing with JTAG and with the bootloader will be the start of the flash. A firmware built to be flashed with the bootloader has to start after the bootloader. This is done by having a different linker script for the bootloader build:
- Normal firmrware https://github.com/bitcraze/crazyflie-f ... 20K_DEF.ld
- CLOAD firmware https://github.com/bitcraze/crazyflie-f ... F_CLOAD.ld

The linker script to use is defined in the main Makefile there: https://github.com/bitcraze/crazyflie-f ... efile#L128

The bootloader scripts reads binary files (out of simplicity). the .elf that comes out of GCC is converted to binary using objcopy: https://github.com/bitcraze/crazyflie-f ... ets.mk#L41

[poizone]

Ok, I'm finding the relevant bits now. If I'm not mistaken, our .ld is misnamed, mentioning only 32K flash. I believe it's flashing for 128K. I've opened up the matching .ld in cleanflight and found this for memory defs:

Code: Select all

/* Specify the memory areas. Flash is limited for last 2K for configuration storage */
MEMORY
{
  FLASH (rx)      : ORIGIN = 0x08003000, LENGTH = 126K - 0x03000 /* last 2kb used for config storage first 12k for OP Bootloader*/

  RAM (xrw)       : ORIGIN = 0x20000000, LENGTH = 20K
  MEMORY_B1 (rx)  : ORIGIN = 0x60000000, LENGTH = 0K
}

Is it acceptable to leave room at 0x08002800 to 0x08003000 as shown above when flashing over the CRadio? I don't really see a downside (Other than less space for firmware) to leaving an extra 2K of space at the end of the bootloader, although I did find the line below in the bootloader:

Code: Select all

.equ  FLASH_PAGE10, 0x08002800

Given that this address matches the CLOAD .ld memory specifications, the only issue I can see is that it won't find the first instruction at 0x08002800. If that's a problem (I'm not familiar with embedded bootloading and firmware in detail) would I simply need to adjust the ORIGIN to be 0x08002800 and LENGTH to be 126K - 0x02800?

[arnaud]

Hi,

I finally got around to document the bootloader in the wiki: http://wiki.bitcraze.se/doc:crazyflie:b ... r:protocol

It is no problem to change where the firmware is loaded, you have two things to change: the PAGE_10 address in multiboot as you noted this would allow to boot the firmware at the right address, and the define FLASH_START in config.h to tell the bootloader clients from where to flash from.