Page 1 of 1

ChibiOS, DFU and Maple bootloader

Posted: Wed Jun 11, 2014 10:17 am
by ejydyo
Hello,
I'm a research fellow at Second University of Naples and I have written a ChibiOS based software to control several types of UAV (drones).
Until now, I have used the Stm32F3 Discovery with onboard sensors and the results are very good.
Now, I want to try the sensors on another famous board, called Aeroquad32. This is a STM32F407 based board that I have to flash by using DFU and the maple bootloader. Is it possible with ChibiOS?
I have written a small sample application with only ChibiOS initialization and a thread to turn a led on and off with a delay. As read on other posts, I have added the

Code: Select all

#define CORTEX_VTOR_INIT 0x00010000
definition in chconf.h and I changed the beginning of the linker script (stm32f407xG.ld) with

Code: Select all

MEMORY
{
    flash (rx) : org = 0x08010000, len = 960k
    ram (rwx) : org = 0x20000C00, len = 112k
}

I think that the address 0x08010000 is correct because to flash the board with the original software I have to use dfu-util with

Code: Select all

--dfuse-address 0x08010000
and also the original aeroquad linker script has the same definition.
The aeroquad bootloader is flashed at 0x08000000 and at start (when I connect the board) it goes into an infinite loop without starting my code.
What is wrong? I checked my code, by flashing an stm32f4 discovery, changing only the flash (and vector) address to 0x08000000 and it works.

I hope I have been able to explain the problem.

Thank you in advance,
Egidio

Re: ChibiOS, DFU and Maple bootloader

Posted: Wed Jun 11, 2014 10:46 am
by Giovanni
Hi,

Probably you have to subtract 0xC00 to the total RAM size, I assume that area is used by the bootloader, right?

Also try to understand where it stops, look at the map file if in doubt.

Giovanni

Re: ChibiOS, DFU and Maple bootloader

Posted: Sat Jun 14, 2014 10:54 am
by ejydyo
Hello,
Thank you Giovanni for your answer!
I tried to do some tests to understand the problem.
Now the linker file starts with:

Code: Select all

MEMORY
{
    flash : org = 0x08010000, len = 1M - 0x10000
    ram : org = 0x20000C00, len = 112k - 0xC00
}

I looked at the map file, but the memory address seems to be ok. I must say that it was the first time I saw a map file, but I looked for the memory address of irq vectors and it's 0x8010000.

I tried to run a code without ChibiOS, starting from a sample code for the stm32f4discovery and it runs correctly, changing only the linker script (in the same way as the above code).
Now, I think that there is something in the starting phase of chibios that generates the loop with the bootloader, but I don't understand where.

Are there other tests that can I do, before reflash the board with another bootloader?
Thank you,
Egidio

Re: ChibiOS, DFU and Maple bootloader

Posted: Sat Jun 14, 2014 11:14 am
by Giovanni
Aren't you able to debug? it loops where exactly?

Giovanni

Re: ChibiOS, DFU and Maple bootloader

Posted: Tue Jun 17, 2014 2:15 pm
by ejydyo
When I start the debug, the first line is the function late_init in crt0. When I go a step over, it goes to 0xffffffff and gdb fails.
I don't know... :(

Re: ChibiOS, DFU and Maple bootloader

Posted: Tue Jun 17, 2014 2:45 pm
by ejydyo
Ok, I tried to modify the linker adding a line with

Code: Select all

ENTRY(ResetHandler)

During the debug, it runs well (Wow), but when I close the debug, reset the board, it goes in loop again!
In debug does it use the bootloader?

Sorry for so many questions, but I am not very skilled and it is difficult to explain what I do step by step.

Thank you

Re: ChibiOS, DFU and Maple bootloader

Posted: Tue Jun 17, 2014 2:50 pm
by Giovanni
I think it skips the bootloader. Apparently it interferes with the startup in some way.

Giovanni

Re: ChibiOS, DFU and Maple bootloader

Posted: Wed Jun 18, 2014 1:53 pm
by mobyfab
It skips the bootloader.

It will load the user app directly in flash and run it from here.
GDB knows the app address from the .elf file.

I had some issues as well as my bootloader starts the watchdog timer :)

Make sure your user app does not rely on the bootloader for testing.