We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Had to add some data logging in a hurry to diagnose an issue.
A function is passed a pointer to data that is then used to assemble a readable string that's then stored on a SD card
the RTOS task that does this has a 8K stack and typically runs at 10% loading up to 80% (Crude observations of the debug options window)
The first version of the code version cause a Hardfault exception at the sprintf instruction.
I do not use the micro Lib and have included retarget.c in the project
unit8_t baBuf[100]; /******************************* * Create the Data ********************************/ sprintf((char *)&baBuf[0],"%08d,%08d,%02d,%02d,%02d,%02d,%02d,%02d,%04d,%04d\r\n", psLIN->lMillsecTimePerDay, psLIN->lDataId, psLIN->bData1,psLIN->bData2,psLIN->bData3,psLIN->bData4, psLIN->bData5,psLIN->bData6,psLIN->wData1,psLIN->wData2);
The second version of the code works as expected
unit8_t baBuf[100]; /******************************* * Create the Data ********************************/ sprintf((char *)&baBuf[0],"%08d,",psLIN->lMillsecTimePerDay); wDataLength = strlen((const char *)&baBuf[0]); sprintf((char *)&baBuf[wDataLength],"%08d,%02d,%02d,%02d,%02d,%02d,%02d,%04d,%04d\r\n", psLIN->lDataId, psLIN->bData1,psLIN->bData2,psLIN->bData3,psLIN->bData4, psLIN->bData5,psLIN->bData6,psLIN->wData1,psLIN->wData2);
Any one have an view on why the first version of the code should be failing ? or is it a case of Please read the manual
thanks Dan
It looks reasonable enough, you might want to look at the assembler view, or a listing, as optimization might distract from the one-to-one code line and flow expectations.
Try to recognize if it's a problem reading one of the parameters, or the call itself, and what address is offending the processor, either for the variable, pointer chain, or stack, etc.
it seems like sprintf does not like the first two arguments and data ( e.g. uint32_t to "%08d,%08d") as long as they are split it works fine.
That sounds like you have stack issues. Have you tried to increase the stack yet?
yup tried increasing the stack size a 1K or so still the same result
perhaps its the format e.g. should be a u or l rather than d
If you want to understand the problem you're going to have to drill down into the assembler code generated, and the processor/register states when the fault occurs.
But if the problem can be recreated in a small test-application with ample stack space, then this is a project that should be handed to Keil support. The code generator should not have any issues with sending 10 or 20 or 50 parameters to sprintf(). And sprintf() itself should use teh formatting parameters to iterate through the parameter values one by one.
So the only real limitation should be that the output buffer is large enough to hold the produced string.