GNAT SPARK:Embedded ARM Ada Project doesn't run in STM32F429 Discovery Board

[alexander.r...@gmail.com]

Hi:

I downloaded and installed gnat-gpl-2014-arm-elf-windows-bin.exe 123 MB May 23, 2014, and followed the tutorial instructions.

The application compiles and the debugger is called, and it seems that it gets programmed on the STM32F4 Discovery board (I have STM32F4 discovery board for the STM32F429 target). Because it is a different board than the one for the F401, the LEDs are connected on Port G and not Port D, so I replaced the references to Port D with references to Port G. I added the GPIO base addresses for Port G as well.

However, after initializing the debugger and starting the program, the LEDs don't turn on, and the debugger doesn't stop at the breakpoint suggested in the tutorial. It seems that it doesn't do anything. The St-Link COM LEDs blink, indicating the the debugger is running, but GPS doesn't show any activity.

This is what GPS shows:

file C:/GNAT/2014/share/examples/gnat-cross/demo_leds-stm32f4/obj/demo
Reading symbols from C:/GNAT/2014/share/examples/gnat-cross/demo_leds-stm32f4/obj/demo...done.
Remote debugging using localhost:4242
0x08000cb0 in _start_rom ()
load C:/GNAT/2014/share/examples/gnat-cross/demo_leds-stm32f4/obj/demo
Loading section .text, size 0x3fc0 lma 0x8000000
Loading section .rodata, size 0x538 lma 0x8003fc0
Loading section .data, size 0x4ac lma 0x80044f8
Start address 0x8000cb0, load size 18852
Transfer rate: 7 KB/sec, 4713 bytes/write.
(gdb) continue
Continuing.



This is what st-util shows:


C:\Users\admin>st-util
2014-08-04T14:09:28 INFO ../src/src/stlink-common.c: Loading device parameters..
..
2014-08-04T14:09:28 INFO ../src/src/stlink-common.c: Device connected is: F42x and F43x device, id 0x10036419
2014-08-04T14:09:28 INFO ../src/src/stlink-common.c: SRAM size: 0x30000 bytes (192 KiB), Flash: 0x200000 bytes (2048 KiB) in pages of 16384 bytes
Chip ID is 00000419, Core ID is 2ba01477.
Target voltage is 2891 mV.
Listening at *:4242...
KARL - should read back as 0x03, not 60 02 00 00
GDB connected.
2014-08-04T14:09:36 INFO ../src/src/stlink-common.c: Attempting to write 16384 (
0x4000) bytes to stm32 address: 134217728 (0x8000000)
EraseFlash - Sector:0x0 Size:0x4000
Flash page at addr: 0x08000000 erased
2014-08-04T14:09:37 INFO ../src/src/stlink-common.c: Finished erasing 1 pages of 16384 (0x4000) bytes
2014-08-04T14:09:37 INFO ../src/src/stlink-common.c: Starting Flash write for F2/F4
2014-08-04T14:09:37 INFO ../src/src/stlink-common.c: Successfully loaded flash loader in sram size: 16384
2014-08-04T14:09:37 INFO ../src/src/stlink-common.c: Starting verification of write complete
2014-08-04T14:09:37 INFO ../src/src/stlink-common.c: Flash written and verified! jolly good!
2014-08-04T14:09:37 INFO ../src/src/stlink-common.c: Attempting to write 16384 (0x4000) bytes to stm32 address: 134234112 (0x8004000)
EraseFlash - Sector:0x1 Size:0x4000
Flash page at addr: 0x08004000 erased
2014-08-04T14:09:38 INFO ../src/src/stlink-common.c: Finished erasing 1 pages of 16384 (0x4000) bytes
2014-08-04T14:09:38 INFO ../src/src/stlink-common.c: Starting Flash write for F2/F4
2014-08-04T14:09:38 INFO ../src/src/stlink-common.c: Successfully loaded flash loader in sram
size: 16384
2014-08-04T14:09:38 INFO ../src/src/stlink-common.c: Starting verification of write complete
2014-08-04T14:09:39 INFO ../src/src/stlink-common.c: Flash written and verified! jolly good!

I have the following questions:

1. Have anyone been able to get the examples running on either F401 or F429 ST Discovery Boards?

2. Do you have a description of the additional runtime libraries, code, that gets loaded prior to running the actual application. The application seems to be stuck somewhere during the initialization?

3. How is the cpu clock gets initialized?

4. If you have any recommendation to get this example running, please let me know. I am very interested in running Ada projects in embedded ARM microcontrollers.


Regards,

Alex

[embeddedr...@scriptoriumdesigns.com]

I've got it running on this board
http://www.mouser.com/ProductDetail/STMicroelectronics/STM32F4DISCOVERY/?qs=sGAEpiMZZMutVogd4PRSvEN8XDBeCtgD

See my c.l.a. post today on Ada on $15 hardware.

It's quite possible that the clock and enabling code is different for the different chip. One thing that often gets forgotten with STM32 chips is that each GPIO port has a separate enable. Have you set the enable for port G, in the proper register?

The code will look something like this:

procedure Initialize is
RCC_AHB1ENR_GPIOD : constant Word := 16#08#;
RCC_AHB1ENR_GPIOE : constant Word := 16#10#;
begin
-- Enable clock for GPIO-D and GPIO-E
RCC.AHB1ENR := RCC.AHB1ENR or RCC_AHB1ENR_GPIOD or RCC_AHB1ENR_GPIOE;

Do you have this code for GPIOG, using the correct RCC register?

Afterwards comes the configuration of the port bits:

-- Configure PD12-15
GPIOD.MODER (12 .. 15) := (others => Mode_OUT);
GPIOD.OTYPER (12 .. 15) := (others => Type_PP);
GPIOD.OSPEEDR (12 .. 15) := (others => Speed_100MHz);
GPIOD.PUPDR (12 .. 15) := (others => No_Pull);
....

[embeddedr...@scriptoriumdesigns.com]

And, of course, you will have had to adjust the port bit numbers to be configured as outputs, and the LED mask values to correspond to those port bits.

[alexander.r...@gmail.com]

On Wednesday, August 6, 2014 12:53:54 AM UTC-4, embeddedr...@scriptoriumdesigns.com wrote:
> And, of course, you will have had to adjust the port bit numbers to be configured as outputs, and the LED mask values to correspond to those port bits.

I checked this too. The LEDs are in PG13 and PG14 (STM32F429 Discovery), so no changes required in the por bit numbers or masks.

[alexander.r...@gmail.com]

Thanks. I had enabled the GPIOG bit in the RCC.AHB1ENR register, but still the program doesn't work.

It might be related to enabling the CPU clock, because it seems as if the application doesn't run.

[alexander.r...@gmail.com]

I got the application working and debugging correctly on the STM32F407 Discovery Board.

Analysis of the system_stm32f4xx.c file (which, it seems, is used for the runtime libraries used by GNAT GPL for STM32) indicates that there are subtle differences in the clock initialization between the STMF32407 and the STM32F429 (PLL settings among others).

[Jerry Petrey]

1. I have it running on the STM407 Discovery board and on the STM417
Discovery Board but have not been able to get it on the STM429 board yet
- that chip is a bit different.

2. You have to look in the lib->gnat->arm-eabi->ravenscar-sfp-stm32f4
directory for the startup files. In adainclude, the file setup_pll.adb
will need some changes as well as s-stm32f.ads, a-intnam.ads, handler.S,
s-bbbosu.adb, and s-bbpara.ads as far as I can tell. Also the linker
script stm32f4-rom.ld in the ada adalib directory will need a change due
to the larger Flash memory.

3. The clocks are setup in setup_pll.adb
4. I think I am getting close to having it run on the 429 board but I am
not there yet. On the other boards it is great. I have console I/O
working, as well as USARTs, interrupts and DMA working.

Jerry

[gnl...@gmail.com]

Hi,

If you are interested I perform the port of Ada runtime library and the demo_leds example. As Jerry wrote the RCC module is a little bit different on the STM32F42x and the origin of the problem came from the voltage scaling operation during initialization.

The main modifications were:
- PLL configuration,
- Add of the 9 new interrupt sources,
- Link command files,
- USART1 configuration update (from GPIOB to GPIOA).

For recall the pins are:
- LED3: PG13,
- LED4: PG14,
- USART1_TX: PA9,
- USART2_RX: PA10.

The LEDs and user button work correctly but I do not test the USART1 yet because I have no TTL<->RS232 converter.

The files are available on GitHub:
https://github.com/gnlnops/gnat-stm32f429i-disco


Regards,

Gnops

[Jerry Petrey]

Good work. I got my port to the 429 board working recently as well.
The voltage scaling issue was what was stopping mine from working before
but I noticed that it had changed in the 429 series while studying some
of the documents from ST. The USARTs work as well on this board.

I now have GNAT Ada working on another board; the F303. I hope to get
it on the Nucleo 401 and 411 boards but those are proving rather difficult.

Jerry

[gnl...@gmail.com]

Great!

I have no plan to work with Nucleo boards for the moment.

What are the main difficulties on STM32F401 and STM32F411?

Gnops

[Jerry Petrey]

I had problems porting the RTS to the Nucleo boards because the st-util
application does not talk to them. I have to convert the elf file
executable to an Intel hex file and then download it to the board via
the ST-LINK GUI.
I couldn't use the GNAT GPS debugger so it was difficult getting anywhere.
I just got a F401 Discovery board and got the GNAT Ada working on it and
now I can use that (with only minor mods) to get the Nucleo 401 and 411
boards working. So far everything looks good. I still have to manually
load the hex files but the Nucleo boards now work. I have an article
coming out soon in "Electronic Design" magazine that describes some of
my work with Ada on the ARM boards. It is really nice to finally have
such a great language on such powerful micro-controllers!

Jerry

[Anh Vo]

I am looking forward to reading your article. Thank you in advance for sharing your work.

A. Vo

[gnl...@gmail.com]

Ok.

I experienced problems too with stlink on ST board STM32F429. I switch on openocd tool (release 0.8.0) to communicate with the board and create the gdb server to connect with GPS. I notice there is a configuration file for the board Nucleo 401 (st_nucleo_f401re.cfg).

I am totally agree with you. It is nice to have the opportunity for beginners, students, hobbyists, and professionals to experiment Ada 2012 on embedded applications in a $30 microcontroller target.

Good luck for your work!

Gnops

[Jerry Petrey]

Thanks Ann,

My article is live today on "Electronic Design" at:
http://electronicdesign.com/ or
http://electronicdesign.com/dev-tools/armed-and-ready

Jerry