I have a problem when try to debug the code which is copied to the SRAM and executed from there.
The code is overwriting the data - but it is done only during the system update. The sections where code is placed are correctly defined in the linker script file and the debuger correctly see the addresses. But when I step into the function (and the code in RAM is the correct one) it does not connect the source files with the code executed in the memory.
Do you know how can it be done. Debugging C code on the assembler level is not something which makes me happy :)
Any help appreciated.
The problem is a bit silly. When you call RAM function from the FLASH (the first call has to be done this way) it has to be done by the veneer. It was messing up the debugger. But having own calling macro (because of the distance it has to be done via the pointer) everything works fine
example calling macro.
#define RAMFCALL(func, ...) {unsigned (* volatile fptr)() = (unsigned (* volatile)())func; fptr(__VA_ARGS__);}
Related
When profiling code with cprofile, I noticed that there appear a lot of numba entries referring to the numba compiler. I know that the computation time is high at the first run of the script due to compiling.
The attached screenshot however shows cprofile entries from a script which already should be compiled (The script was run at least twice and also the total computation time decreased).
Because the functions shown in the screenshot still consume a lot of time, I asked myself if I do anything wrong using numba. Additionally, it does not make sense to call a compiler function if the code is already compiled. Is there a way to find out if compiled functions are already in storage?
I started a new project using an STM32H7, currently using IAR EWARM V8, used the STM32CUBEMX to generate the configuration code, and get an initial project going.
I worked through a couple of the CUBEMX eval projects to get some hardware verified and working, and am able to step through code fine.
But there is something odd going on, in particular with variables if you assign them as local vars within a function, somehow IAR is placing them into the 'System Reserved' memory range...
ie within 0x1FF20000 - 0x1FFFFFFF
For example... the project example 'FMC_NOR' that STM provides, is test code for testing our a NOR flash, etc..
they created these two small arrays as globals vars just at the top of the main.c file.
(buffer_size is 0x1000)
uint16_t aTxBuffer[BUFFER_SIZE] = {0};
uint16_t aRxBuffer[BUFFER_SIZE] = {0};
When in the global space, they are allocated in the DTCM region (0x2000:0000)
When moved as local vars, they then become allocated into the 'reserved space'...
What happens is, when IAR encounters any arrays like this, the processor faults with an 'imprecise data access' hardware fault.
This same error occurs with code to initialize the JPEG module, as it attempts to load the arrays of Huffman tables, etc...
When using TrueStudio this problem does not occur... CubeMX auto-generates the linker files for whichever compiler you are using.
I didn't specifically see anything in the linker files pointing to the reserved memory address.
So not sure what could be going on? I'm new to using this processor, so I'm just starting to understand it's memory mapping.
Thanks for any help or suggestions, I'd like to get IAR figured out, as so far I like it a bit over TrueStudio.
I solved my own question... so no longer need help on this...
This is in the 'stm32h743xx_flash.icf' generated by STM CUBEMX for the STM32H7...
/*-Sizes-*/
define symbol __ICFEDIT_size_cstack__ = 0x400;
define symbol __ICFEDIT_size_heap__ = 0x200;
/**** End of ICF editor section. ###ICF###*/
Bumped the 'size_cstack' up to 2k (0x800) and everything is fine...
I'm working on a project based on the stm32f4discovery board using IAR Embedded Workbench (though I'm very close to the 32kb limit on the free version so I'll have to find something else soon). This is a learning project for me and so far I've been able to solve most of my issues with a few google searches and a lot of trial and error. But this is the first time I've encountered a run-time error that doesn't appear to be caused by a problem with my logic and I'm pretty stuck. Any general debugging strategy advice is welcome.
So here's what happens. I have an interrupt on a button; each time the button is pressed, the callback function runs my void cal_acc(uint16_t* data) function defined in stm32f4xx_it.c. This function gathers some data, and on the 6th press, it calls my void gn(float32_t* data, float32_t* beta) function. Eventually, two functions are called, gn_resids and gn_jacobian. The functions are very similar in structure. Both take in 3 pointers to 3 arrays of floats and then modify the values of the first array based on the second two. Unfortunately, when the second function gn_jacobian exits, I get the HardFault.
Please look at the link (code structure) for a picture showing how the program runs up to the fault.
Thank you very much! I appreciate any advice or guidance you can give me,
-Ben
Extra info that might be helpful below:
Running in debug mode, I can step into the function and run through all the lines click by click and it's OK. But as soon as I run the last line and it should exit and move on to the next line in the function where it was called, it crashes. I have also tried rearranging the order of the calls around this function and it is always this one that crashes.
I had been getting a similar crash on the first function gn_resids when one of the input pointers pointed to an array that was not defined as "static". But now all the arrays are static and I'm quite confused - especially since I can't tell what is different between the gn_resids function that works and the gn_jacobian function that does not work.
acc1beta is declared as a float array at the beginning of main.c and then also as extern float32_t acc1beta[6] at the top of stm32f4xx_it.c. I want it as a global variable; there is probably a better way to do this, but it's been working so far with many other variables defined in the same way.
Here's a screenshot of what I see when it crashes during debug (after I pause the session) IAR view at crash
EDIT: I changed the code of gn_step to look like this for a test so that it just runs gn_resids twice and it crashes as soon as it gets to the second call - I can't even step into it. gn_jacobian is not the problem.
void gn_step(float32_t* data, float32_t* beta) {
static float32_t resids[120];
gn_resids(resids, data, beta);
arm_matrix_instance_f32 R;
arm_mat_init_f32(&R, 120, 1, resids);
// static float32_t J_f32[720];
// gn_jacobian(J_f32, data, beta);
static float32_t J_f32[120];
gn_resids(J_f32, data, beta);
arm_matrix_instance_f32 J;
arm_mat_init_f32(&J, 120, 1, J_f32);
Hardfaults on Cortex M devices can be generated by various error conditions, for example:
Access of data outside valid memory
Invalid instructions
Division by zero
It is possible to gather information about the source of the hardfault by looking into some processor registers. IAR provides a debugger macro that helps to automate that process. It can be found in the IAR installation directory arm\config\debugger\ARM\vector_catch.mac. Please refer to this IAR Technical Note on Debugging Hardfaults for details on using this macro.
Depending on the type of the hardfault that occurs in your program you should try to narrow down the root cause within the debugger.
The answer to this question here
Libopencm3 interrupt table on STM32F4
explains the whole mechanism nicely but what I get is whole vector table filled with blocking handlers.
I know that because I see it in debugger (apart from the whole thing not working): disassembly screenshot showing vector table.
It is as though linker simply ignores my nicely defined interrupt handler function(s), e.g.:
void sys_tick_handler(void)
{
...
}
void tim1_up_isr(void)
{
...
}
I am using EmBitz IDE and have followed this tutorial here to get libopencm3 to work (and it does work except for this issue).
I have checked the function names n-fold and have tried several online examples including those from the libopencm3-examples project.
Everything compiles without a glitch and loads into the target board (STM32F103C8) and runs fine - except no ISRs get invoked (I do get interrupt(s) but they get stuck in blocking handlers).
Does anyone have an idea why is this happening?
It looks like linking with standard vector table (from ST's SPL or HAL).
To check this, try to rename your sys_tick_handler() to SysTick_Handler() and
tim1_up_isr() to TIM1_UP_IRQHandler().
If it works, find file with this SysTick_Handler and TIM1_UP_IRQHandler (I think, that will be startup*.s) and delete it from your project.
has anyone experience the following issue?
A stack variable getting changed/corrupted after calling ne10 assembly function such as ne10_len_vec2f_neon?
e.g
float gain = 8.0;
ne10_len_vec2f_neon(src, dst, len);
after the call to ne10_len_vec2f_neon, the value of gain changes as its memory is getting corrupted.
1. Note this only happens when the project is compiled in release build but not debug build.
2. Does Ne10 assembly functions preserve registers?
3. Replacing the assembly function call to c equivalent such as ne10_len_vec2f_c and both release and debug build seem to work OK.
thanks for any help on this. Not sure if there's an inherent issue within the program or it is really the call to ne10_len_vec2f_neon causing the corruption with release build.enter code here
I had a quick rummage through the master NEON code here:
https://github.com/projectNe10/Ne10/blob/master/modules/math/NE10_len.neon.s
... and it doesn't really touch address-based stack at all, so not sure it's a stack problem in memory.
However based on what I remember of the NEON procedure call standard q4-q7 (alias d8-d15 or s16-s31) should be preserved by the callee, and as far as I can tell that code is clobbering q4-6 without the necessary save/restore, so it does indeed look like it's clobbering the stack in registers.
In the failed case do you know if gain is still stored in FPU registers, and if yes which ones? If it's stored in any of s16/17/18/19 then this looks like the problem. It also seems plausible that a compiler would choose to use s16 upwards for things it needs to keep across a function call, as it avoids the need to touch in-RAM stack memory.
In terms of a fix, if you perform the following replacements:
s/q4/q8/
s/q5/q9/
s/q6/q10/
in that file, then I think it should work; no means to test here, but those higher register blocks are not callee saved.