I've been dealing with an extremely frustrating problem with the bootup of the microcontroller. I'm working with the F28M35H52C1 Rev B.
Upon making seemingly innocuous and arbitrary changes to my code, the microcontroller fails to boot up properly, always ending up stuck in the same place in TI's ADC calibration code, specifically at this line:
while (Adc1Regs.ADCINTFLG.bit.ADCINT1 == 0) {}
This is in the funciton Uint16 Adc1Conversion(void) within the file F28M35x_Adc.c.
The changes that trigger this bootup bug have nothing to do with the ADCs, have nothing to do with bootup, and indeed sometimes are never called from anywhere in the code. The mere presence of this code triggers the bootup bug.
Here is an example of code that triggers the bug:
float ABO::GetMagnitude()
{
return InvSqrt(A*A + B*B);
}
This is just returning the magnitude of a vector. Here is the seemingly trivial change that fixes the bug, and allows the microcontroller to boot up properly:
float ABO::GetMagnitude()
{
float mag = InvSqrt(A*A + B*B);
return mag;
}
The only change was storing the return value in a local variable first. This is utterly incomprehensible to me.
Note that sometimes, I need to change code the other way to get it to work - meaning I need to remove a local variable and return the value directly. Also, after some time has passed and multiple revisions have been made in the overall code, I can come back to the example shown and revert the "fix" without triggering the bootup bug. But I can check out the faulty commit from history again and faithfully reproduce the bug.
Note that this is just ONE example of code that breaks the bootup. Other seemingly innocuous changes also trigger the bug. Examples include commenting out an empty function that is not called from anywhere; commenting out a global variable that is not used anywhere; and other similar arbitrary examples that do not make sense to me.
This bug seems completely arbitrary based on my code, but it is not random! It is deterministic. The same code will always exhibit the bug or not.
If I had to try to use an analogy for my experience with this bug, the best thing that comes to mind is that it's as if the bug happens when a hash function of my code is divisible by 3, or something silly like that. Completely arbitrary, seemingly chaotic, but deterministic.
I've tried multiple controlCards, (all RevB), and it is consistent across control cards. I've tried it from multiple computers, with different versions of CCS and the compiler, and it does not matter. I've tried increasing the stack size, which does not fix the bug. I've tried increasing the size of various memory blocks in the linker command file, and nothing fixes the bug.
This bug sometimes doesn't show up for days, but when it does, I then have to go back and revert changes to my code until I find the source, then figure out which arbitrary line is causing it and then figure out which meaningless code change (like storing the return value in a local variable first) fixes the issue. It's frustrating.
I hope I've provided enough information to help track down the issue. Any help is greatly appreciated. This issue has been extremely frustrating to my team.