STM32F4 progress - I want to change all the interrupt vectors

LeafLabs Garden » Community » The Lounge

STM32F4 progress - I want to change all the interrupt vectors

(15 posts) (5 voices)

Started 3 years ago by gbulmer
Latest reply from gbulmer

gbulmer
Moderator

I have been working with ala42's STM32F4 library
http://forums.leaflabs.com/topic.php?id=1268&page=2#post-7828

I have also been working with ST Micro's libraries and examples. It is not possible to mix ala42's interrupt vector names with the ST's libraries, and vice versa.

I have changed all of the interrupt vector names in ala42's code so that they all match the ones ST Micro use in their libraries and projects.

This allows me to successfully compile, link and run ST Micro's own STM32F4 peripheral library, and some of their projects. For example I have their IO_toggle and MEMS 3D-accelerometer demo working on my STM32F4Discovery.

The interrupt names are straightforward to find from the ST Micro's STM32F4 documentation without looking at the source code. The names follow a simple rule.

This is such a pervasive change to ala42's code that I feel I should ask for feedback. I am especially asking ala42.

I also thought folks working with ala42's library may have written their own code which uses the existing vector-names in ala42's library.

So I have written an 'ed' script which will edit source code, and change the interrupt vector names 'automatically'.

Folks can apply this technique to their source. That would bring us to a set of sources which share the same interrupt vector names. That would allow us to mix and merge our source code, which I feel is very important.

Will my 'ed' script be adequate for anyone working on the source who has a lot of code which uses those interrupt names? Specifically, is there anyone working on the source, who would need to change a lot of interrupt vector names, who don't have 'ed' (i.e. more than 10 minutes of hand editing and testing)?

I think there is huge advantages in using the same vector names as ST. We get all of their projects to run on STM32F4-based boards and can use their projects to test boards and electronics. Their code may be ugly, but I'll take ugly and mostly-works over most alternatives :-)

My goal is to ensure we can use an STM32F4 libmaple-style/wiring-style library at the same time, in the same program (sketch) as ST's code.

The same technology (ed) I use to change ala42's interrupt-vector names can be used to change them to something else, so I don't think there is much of a problem.

Question:
What objections are there to me pushing all of my vector-name changes, into the ala42-based openstm32sw/stm32f4 github repo?
I will also push my ed-script too so folks can bring their source in-line.

I will wait until Friday before pushing to give folks time to think and respond.

Posted 3 years ago #
ThomasB
Member

@My goal is to ensure we can use an STM32F4 libmaple-style/wiring-style library at the same time, in the same program (sketch) as ST's code.

Whow! This would be really cool :)

The ST lib is a sourcecode base, which is well known by a lot of developer.
And if a programmer has questions or problems, the chance that google can help is bigger.

Posted 3 years ago #
mikep
Member

+1
I think it would help people getting their problems solved and maybe contribute their solutions as well. I think at some point there was an issue about the questionable license terms of the ST libraries, but for most of us hobbyists here that is really a non-issue.

Posted 3 years ago #
bubulindo
Member

That would be awesome. :)

I got completely sidetracked from the STM32F4 stuff I was doing, but hopefully can come back not long from now.

@gbulmer, did you get the USB communication going?

Also, what would be the must haves for an expansion board? So far I thought of an SD card slot, Xbee interface (or FTDI interface) and if would be nice to include an LCD, or a simple connection possibility for one.

Posted 3 years ago #
ala42
Member

>The interrupt names are straightforward to find from the ST Micro's STM32F4 documentation without looking at the source code. The names follow a simple rule.
While this might be the case, it would be a lot easier you link your changes so I can have a look at it :)

Posted 3 years ago #
gbulmer
Moderator

ala42

...it would be a lot easier you link your changes so I can have a look at it :)

Doh! Sorry about that folks

Here is the version of the vector table which contains some explanatory comments:
http://pastebin.com/2EyfCPez

@bubulindo - I have not got the USB connection going. I am hoping ST's code will mostly work.

Posted 3 years ago #
gbulmer
Moderator

BTW - I believe all of the startup code can be written in C, including the interrupt vector table, and the code to switch on the FPU.

It is not a high-priority for me, but seems like a 'nice to have'.

It might help anyone interested to get to the bottom of everything.

Posted 3 years ago #
ala42
Member

I extended the maple vector table by the additional vectors supported by the F4, so the last entries were made by me, all previous by leaflabs. Looks like I added the __irq_ prefix so they look more like the previous maple entries.
Don't you get linker errors when the ST code uses the same vectors already used by the libmaple code, e.g. with the timer and usart vectors ?

Posted 3 years ago #
gbulmer
Moderator
ala42

I extended the maple vector table by the additional vectors supported by the F4 ...

Yes I understood that.

Don't you get linker errors when the ST code uses the same vectors already used by the libmaple code ...?

Yes-ish.

If I try to build a program with multiple interrupt or exception handlers with the same name, yes there are link errors. A human being has to decide what to do about . The way I'd explain that is "I get linker errors when ST code and libmaple both supply the handler code for the same interrupt or exception vector".

This isn't always a problem because often the ST code supplies a handler which is:
```
void DebugMon_Handler(void)
{
}
```
or
```
void BusFault_Handler(void)
{
  /* Go to infinite loop when Bus Fault exception occurs */
  while (1)
  {
  }
}
```
An approach is to edit the ST Project, and 'throw away' all of those 'empty' handlers.

Even this isn't too difficult because the file is always (almost always?) called stm32f4xx_it.c

The handlers have well defined names (they are interrupt or exception vector names) so it could be done 'auto-magically' with a script if the task became large and onerous.
Posted 3 years ago #
ala42
Member

To answer your question of your first post, I have nothing against renaming the vector names for better compatibility with the STM libraries.

Posted 3 years ago #
gbulmer
Moderator

ala42 - thank you. Busy, so will push over the weekend.

Posted 3 years ago #
ala42
Member
I just noticed that the Makefile does not set the STM32_HIGH_DENSITY flag referenced in stm32_vector_table.S, so the additional vectors are missing. This bug exists in the libcs3_stm32_src and libcs4_stm32_src directory. You can fix it by adding
```
high-density: ASFLAGS := -DSTM32_HIGH_DENSITY
```
to Makefile in line 28.

Bad libcs3_stm32_high_density.a or libcs4_stm32_high_density.a look like
```
0004c0  74 63 61 6c 61 72 6d 00 5f 5f 69 72 71 5f 75 73  tcalarm.__irq_us
0004d0  62 77 61 6b 65 75 70 00 5f 73 74 61 72 74 00 5f  bwakeup._start._
0004e0  5f 63 73 33 5f 73 74 61 72 74 5f 63 00 00 2f 2f  _cs3_start_c..//
```
Good libs contain the text __irq_tim8_brk like
```
000500  72 71 5f 72 74 63 61 6c 61 72 6d 00 5f 5f 69 72  rq_rtcalarm.__ir
000510  71 5f 75 73 62 77 61 6b 65 75 70 00 5f 5f 69 72  q_usbwakeup.__ir
000520  71 5f 74 69 6d 38 5f 62 72 6b 00 5f 5f 69 72 71  q_tim8_brk.__irq
```
The default libcs3_stm32_high_density.a from libmaple 0.0.12 also has this bug.
You can also detect the bad libcs3_stm32_high_density.a from the file length. Same length as libcs3_stm32_med_density.a means buggy lib.

Took me some hours to understand why my program crashed when I enabled the OTG_FS irq and why OTG_FS_IRQHandler was never called.
Posted 3 years ago #
gbulmer
Moderator

ala42 - sorry for the slow response. Been busy.

I don't think we need two variations of the STM32F4 interrupt vectors do we?

AFAICT, the 405/415/407/417 STM32F4 members have the same interrupt vectors.
The 405/415 won't use the ethernet vector because they have no ethernet peripheral, but AFAICT vectors don't move because of that.

So, I think STM32_HIGH_DENSITY should be removed. Yes?
You've made me all nervous now B-/

Posted 3 years ago #
ala42
Member

You can remove the ifdef or define it in the makefile, as you want, but it is still buggy for the F1 and also needs to be fixed there.

Posted 3 years ago #
gbulmer
Moderator

ala42 - just got home, off to bed. I think I suddenly understand! I'll have a look in the morning.

Posted 3 years ago #

RSS feed for this topic

Reply

You must log in to post.