Author Topic: Cortex M7 debugging bug  (Read 1393 times)

0 Members and 1 Guest are viewing this topic.

Online daqq

  • Super Contributor
  • ***
  • Posts: 1823
  • Country: sk
    • My site
Cortex M7 debugging bug
« 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

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.
Believe it or not, pointy haired people do exist!
+++Divide By Cucumber Error. Please Reinstall Universe And Reboot +++
 

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 3516
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: Cortex M7 debugging bug
« Reply #1 on: December 08, 2017, 07:43:32 am »
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.
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 2777
  • Country: fi
Re: Cortex M7 debugging bug
« Reply #2 on: December 08, 2017, 08:08:33 am »
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:

Code: [Select]
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:

Code: [Select]
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.
« Last Edit: December 08, 2017, 08:14:40 am by Siwastaja »
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 19839
  • Country: nl
    • NCT Developments
Re: Cortex M7 debugging bug
« Reply #3 on: December 09, 2017, 01:23:58 am »
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 
The following users thanked this post: hans

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 3516
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: Cortex M7 debugging bug
« Reply #4 on: December 09, 2017, 01:52:07 pm »
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.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf