EEVblog Electronics Community Forum
Electronics => Microcontrollers => Topic started by: daqq on December 08, 2017, 07:39:27 am
-
So, there's a bug in the debugging of the Cortex M7 core... it's a bug in the silicon, in the ARM core actually.
http://www.keil.com/support/docs/3778.htm (http://www.keil.com/support/docs/3778.htm)
I'm now strugling with an STM32F7 device... and it's pretty annoying.
I'd have assumed that they test for stuff like this. This isn't exactly a subtle bug that shows its head when the phase of the moon is right.
-
Can you isolate the software that you want to step trough?
I've never gotten any usable results from debugging in full code. Since the surrounding real world does not halt.
-
Same as Jeroen3, I found out that stepping through code in debugger is helpful so rarely that I stopped doing it entirely.
I mostly need that kind of "debugging" when accessing with outside world (or with complex time-dependent accesses with peripherals, like DMA), which can't be halted. A typical approach I use is something like this:
original_code()
uint32_t tmp1 = INTERESTING_REGISTER;
more_original_code()
uint32_t tmp2 = INTERESTING_REGISTER;
more_original_code()
....
when you have time:
printf("%x, %x\n", tmp1, tmp2);
Or, for example, just a few days ago I debugged strange issues with DMA-driven I2C and DCMI (camera interface) interfacing with a CMOS sensor, and did it like this:
uint32_t snapshots[1000];
start_i2c_transfer_here();
for(int i=0; i<1000; i++)
{
snapshots[i] = interesting register, pin state, whatever;
blink_io_pin_to_sync_the_datatrace_with_oscilloscope
}
print_snapshots_here();
This gives minimal interference and allows you to fine tune what you gather and when. Of course slower to write than just looking at the debugger screen, but with this kind of creative approach, you can basically solve all the issues that come to you, whereas the debugger always has serious limits in regards to application timing.
-
I do the same as Siwastaja and Jeroen3 when it comes to on-target debugging or getting some real data from a device. Usually I debug/unit test code on a PC first because in that case I can run all kinds of scenarios and I'm not limited by a debug interface which may or may not work for various reasons.
-
STM studio is helpful. Although full of traps for young players.
It reads memory as fast as it’s allowed, but it’s doing this at an irregular interval.
While sometimes helping you tackle a bug, it can also send you hunting for ghosts if you’re not paying attention.
It also can’t read 64 bit values.