#370 profile : Assertion `address_space >= 2' failed.

[fenugrec]

Hi,
trying to profile a cortex-M0 target (stm32F042) with a jlink . If I don't specify Start and End :

(gdb) monitor profile 5 test.out               
[stm32f0x.cpu] Starting Cortex-M profiling. Sampling DWT_PCSR as fast as we can...
[stm32f0x.cpu] Profiling completed. 10000 samples.
openocd: src/target/target.c:4258: write_gmon: Assertion `address_space >= 2' failed.
[stm32f0x.cpu] halted due to debug-request, current mode: Thread 
xPSR: 0x21000000 pc: 0x08002142 msp: 0x20001760
Remote connection closed                     

Should probably either

• offer default values for those args
• abort and complain if the args are mandatory
• not require them at all

Sidenote, a hardcoded limit of 10k samples ??

[Antonio Borneo]

yes, this code has two ugly abort() when it should just report an error or a warning.
That's a kind of old coding style that is still present here and there in OpenOCD.

In your case, the PC is sampled but it always returns the same value
Is target running in an infinite loop?
Or maybe your M0 does not implements PC sampling and reading register DWT_PCSR returns zero.
The code computes min and max PC and if it finds that min and max are the same it abort() instead of printing an error or something useful.
You can verify that the PC is always the same value running few times
mdw 0xE000101C
but not from GDB, because GDB let you type the command only with target halted.
You need to telnet in OpenOCD with
telnet 127.0.0.1 4444
then type few times the mdw command above

[fenugrec]

Thanks.

In your case, the PC is sampled but it always returns the same value

I doubt that - I eventually got a proper trace by giving Start and End args» :

Each sample counts as 5.66027e-05 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls  Ts/call  Ts/call  name    
  3.39      0.02     0.02                             USB_ReadInterrupts (stm32f0xx_ll_usb.c:680 @ 8002143)
  2.45      0.03     0.01                             led_update_normal_mode (led.c:103 @ 8000cd0)
  2.26      0.05     0.01                             USB_EPStartXfer (stm32f0xx_ll_usb.c:511 @ 80026c0)
  1.30      0.05     0.01                             PCD_EP_ISR_Handler (stm32f0xx_hal_pcd.c:1675 @ 8003e7e)
  1.22      0.06     0.01                             USB_ReadPMA (stm32f0xx_ll_usb.c:766 @ 8002aa6)
  1.13      0.07     0.01                             USBD_LL_Start (usbd_conf.c:189 @ 800213e)
  1.01      0.07     0.01                             main (main.c:126 @ 80046f8)
  0.95      0.08     0.01                             USB_WritePMA (stm32f0xx_ll_usb.c:726 @ 800216a)
  ...

maybe your M0 does not implements PC sampling

Yes it does, DWT_PCSR is documented in the ref manual for stm32F042.

Still, for thoroughness, I just manually ran a few "mdw 0xE000101C" and getting different PC values, as should be.

[Antonio Borneo]

Would you mind checking
https://review.openocd.org/7394/
and report if it fixes your use case?

[fenugrec]

Thanks, but no - see my comments on gerritt. I believe it has to do with cortex-M0 sometimes having the magic value 0xfffffff9 in LR/PC on return from interrupts

[fenugrec]

My bad - it does indeed fix the assert() failure , I got mixed up with 2 different targets with different firmware (one of which has an empty while(1) which indeed returns only 1 value for PC). I replied on gerritt but somehow the comment disappeared.

[Antonio Borneo]

This extra patch addresses the case of PC constant due to 'while (1);'
https://review.openocd.org/7400/

[Antonio Borneo]

Patches merged