2019-05-23 07:41 AM
Hello all, I am still attempting to create my project on the STM32F411RE that is capable of taking in 3 sinusoidal signals and return the frequencies + amplitudes for these signals. Thus I need to use the CMSIS-DSP pack, but this is continuously giving me all sorts of random errors which I cannot seem to fix.
Because I cannot get my original code to work yet, I took a step back and made a very simple program to find the frequency and bin for a combined sinus signal. Steps:
When I run my code (https://pastebin.com/37n0fS1F) I get a Hard Fault Error which I cannot find out how to resolve:
Bus, memory management or usage fault (FORCED)
Precise data access violation (PRECISERR)
Bus Fault Address Register (BFAR): 0x20020000
For this I looked at the Fault analyzer in screenshot above, but I cannot figure out which line is causing the error in my program. I have been studying this document, but I with it I cannot solve my problem.
I am starting to get discouraged by the STM32, as even implementing basic examples seems to be fraught with error. Debugging is all part of the game, but this seems largely excessive.
For example, when I include the code
status = arm_rfft_fast_init_f32(&inst, fftLen);
which is supposed to tell me the status of the mathematical operations, I can no longer upload the code to my STM32 board via the CubeProgrammer. Literally just commenting this code allows me to upload it again.
I also attempted to use multiple calls of arm_max_f32() function to find the multiple maximums of the input signal, but this obviously wont work as it is a redefinition instead. I tried looking up how to access specific frequencies inside the FFT output to find the associated magnitudes but I cannot find how to do this either.
2019-05-25 01:19 AM
Yep. I vaguely remember that r0 contains the first parameter and r1 the second, and r2 the 3rd, and the rest in stack.
In that case the first parameter (pointer) is possibly bad. I don't think the second field of the struct pointed to by the second parameter ([r1, #2] is that big to cause access above the RAM into the reserved address area. Possible, though.
[edit]
Checked: also r3 is used for parameters, and after that the stack is used.
2019-05-25 02:30 AM
BTW, since I, too, have been bothered by hard faults, I decided to look into it a bit more.
Especially I wondered why bad address usually cause a hard fault.
The reason seems to be that usually bus faults etc. are disabled, so bus faults etc. are escalated to hard faults.
2019-05-27 07:32 AM
@turboscrew @Community member I was ultimately able to make my code function, in no small thanks to you guys! Unfortunately I cannot figure out why the broken code did not function and why the working one does, as to my limited coding abilities both source files appear to perform the same functions.
The only two differences I can identify is that:
Sorry to have such an inconclusive update, if I find out what caused this error I will report back, but that could be a long while.