I am working on a data logger code. It is basic at the moment.
1, set a an ISRTimmer for 1sec.
2, When ISR triggered i set DataLoggerFlag.
3, Next loop thru main() i test DataLoggerFlag, if set go to a function and read A0, A1 ports and store back into an array i have set up.
Every time i run this code it completes 5 successful loops but it always crashes on the 6th loop in the same spot reading A1.
The Fault has the same sequence. 1, call A1 read, 2, straight to HardFault_Handler. According to the stack it happens straight after the osKernalStart (see attached pic).
I was wondering if this is an ISRtimmer conflict with ADC issue?
Any tips would be greatly appreciated
Set Up;
Portenta H7 (STMH7), VS Code using PIO
Update
pretty sure it is not an ISR / ADC conflict, i tested with varying timer intervals and it still crashes at same point.
Here is my sampleRead() function
int sampleRead(){
sampleCount++;
samPacket[sampleCount].sdKey =tdbsKey;
samPacket[sampleCount].samSequenceNo= sampleCount;
samPacket[sampleCount].samTimerLast = sampleCount;
samPacket[sampleCount].sdData1 = anaReadPort(0);
samPacket[sampleCount].sdData2 = anaReadPort(1);
samPacket[sampleCount].samTimer = packetTimer;
return sampleCount;
}
Every time on the 6th iteration of my code it fails when stepping into next line.
anaReadPort(0)
ie if i comment out anaReadPort(1), it will fail when stepping into
packetTimer
Here is the stack before calling packetTimer
here is the stack after stepping into packt timer
Is this an ST-Link issue? BTW it fails when im using debugger or just straight uploading.
Maybe it’s a stack overflow because the anaReadPort() function is too stack heavy to execute. Or sampleCount is incremeneted beyond the number of elements in the samPacket array. Is the complete code sharable?
You can also get more info from the hardfault if you implement a hardfault handler to print more info, by e.g. adding https://github.com/armink/CmBacktrace/tree/master to the project.(fault_handler/gcc/cmb_fault.S and all cm* files specifically, and adapt cmb_cfg.h.
You should be able to find the exact instruction it faults at and for what reason it does.
I have found the issue but im not sure exactly what is going on. it appears i have overloaded a variable due to a silly coding issue.
My code has two counters
uint32_t tdbsKey = 0; // Packet Counter
uint32_t sampleCount = 0; // Samples per Packet
Quite simple, plan was to get 60 odd samples, than average and send them to the packet for storage using TDBStore.
I managed to place “tdbsKey” where it was counting every loop of my main. very silly i know.
My code was crashing in the 6th sample of the 1st packet. But the weird thing is entering sampleRead() “sampleCount = 5 and increments to 6” and “tdbsKey = 1070358”. Look at watch window.
Then after i execute samPacket[sampleCount].sdKey =tdbsKey;
sampleCount goes to 1070358, ie equal to tdbsKey.
it almost like “tdbsKey” has overloaded and bleed into “sampleCount”. Is this possible?
Thanks for the Handler investigation code. I will implement now and see if that helps. As well as fixing the counting of “tdbskey” cheers.
Hi thanks for all the help
i tried to get
CmBacktrace/cm_backtrace at master · armink/CmBacktrace · GitHub
but i kept chasing my tail and couldnt get it working.
Cheers
Ok every time i think im getting to bottom of this one another question comes up.
I fixed “tdbsKey” so it only counts the packets. Now it doesnt overflow the stack.
BUT, on the 6th sample of Packet 1 i still get problems. I know what triggers the problems. Another stupid error, i was reffering to my samplePacket array as Base 1 instead of Base 0.
i define my Array as
const uint samplePacketSize = 6; // Amount of samples per packet
dlSdSample samPacket[samplePacketSize]; // Sample Packet
So i should index samplePacket[ ] 0 to 5. that is cool i understand that.
But when i do try to write to samPacket[sampleCount].sdKey =tdbsKey; //where sampleCount =6
“sampleCount” is set to “tdbskey” = 1, see Below
Why does sampleCount spontaneously go from 6 to 1?
So you have an out of bounds write. It will overwrite whatever variable comes after the allocated samPacket[] memory.
