I make file browser with st32f746 discovery When some string functions (like strchr strcat) on file path or on some touch pointer Sddriver stuck at driver initialize and after check I found it stuck at enable widebus 4b and if I cancelled that step in driver or changed to 1 b itworks I'm sure it is not driver or card problem It is some pointers or string functions
If any one face like that problem please help
Not sure why you write: "I'm sure it is not driver or card problem It is some pointers or string functions"
There is not likely any problems with strchr(), strcat() etc. But you might have written code that has buffer-overrun problems, in which case you might corrupt other data. Then no one but you can help you, since the problem must be solved by reading through the code and verify all operations and all used data.
I need to exclude some points so I can go for others When I say not driver or card then I do not go for that side I need your help to understand I'm new to embedded C I just come from pic asm and visual basic I need to know why I have to use 1b wide bus so problem solved And why when I use string functions in some places in code problem happen Just I need your experience on which way I should think And what is better to use fatfs structs as stack copy or pointer in heap I need guide lines And thanks for help
The problems likely aren't directly coupled. The interaction will be far more mundane, so don't focus on the wrong issue.
Make sure your aren't trashing your environment, corrupting structures and variables.
String functions expect NUL terminated strings, and buffers large enough to hold the data being written. C does not automatically allocate memory for pointers, and the stack and heap initially set up by Keil are small and finite. Embedded is far less forgiving for large local/auto variables
thanks Pier for help after using debug i found that path name array was defined as global but i didnot find any reference in stack so i made it local in main file and passed it as char pointer all conflicts gone and i will go for next step is text viewer module be ready for problems :)
Global variables are not stored on the stack.
So if you had a too small global variable that you overwrote, then you should figure out if the global variable was too small or if the code that produced the overwrite was buggy or received incorrect input data.
Changing from a global variable into an auto variable (i.e. a variable on the stack) might remove your immediate problem. But you might still have a buffer overrun problem - just that with the variable moved, the overwrite will overwrite other data giving other issues.
I would suggest you return back to your global variable and figure out how big it was and how large the data you wrote was. Or if you had forgotten to store reasonable content in the variable.
When debugging, you are expected to figure out _why_ something fails. Then fix that issue. Just changing code until you no longer see symptoms might possibly result in the bug being fixed. But it might also result in still buggy code that just errs in a different way.
one by one still i'm learning let the code run first :) now i decided to depend on malloc to save memory and to build modules with pointer to structs i want to malloc array of struct i do this but it look like that it allocated only one item ______________________________________________________________________________ TouchItem *TcArray = (TouchItem *)malloc(TC_COUNT*sizeof(TouchItem)); _____________________________________________________________________________ is that enough or i have to allocate each item in array ??
regards
This is more C rather than Embedded related
TouchItem *TcArray = (TouchItem *)malloc(TC_COUNT * sizeof(TouchItem));
This would allocate space for TcArray[0] thru TcArray[TC_COUNT-1]
If you wanted an array of pointers, and then individually allocate the data structures they point too it would look more like this
TouchItem **TcArray = (TouchItem **)malloc(TC_COUNT * sizeof(TouchItem *)); // Allocate POINTER space TcArray[0] = (TouchItem *)malloc(sizeof(TouchItem)); // Allocate a STRUCT and put it's address into the array of pointers
Note that small microcontrollers and malloc() might not always be a good idea.
If the data will live through the full lifetime of the program and you already know the number of elements, then the data can be statically allocated and you can have the compiler help you with range checking etc directly when you compile.
If the data needs to be allocated/freed many times during execution, then you might get memory fragmentation so your program starts to fail with allocations even if the heap actually have enough space free - it's just that the free space has been split into many small fragment that are too small for your request.
It can be hard to test for potential fragmentation issues since the failures might not be seen until the device has been running for weeks or months. But people can be sad if their alarm clock or microwave oven hangs every three months and they have to remove the battery or unplug the power coord just to force a restart.
Never switch technology (in this case static -> auto -> dynamic allocation) as a way around a bug instead of actually trying to locate the bug. You should only switch technology if you find that you gain actual advantages - not as a way to randomly rewrite the code until it stops failing.