cancel
Showing results for 
Search instead for 
Did you mean: 

Deferred Debugging Activity - Debugger Freezing

lbs
Associate

I am working on a project for an OEM's proprietary board firmware package (developed/baked from scratch), which has been developed from scratch with reference to two OEM's proprietary board firmware packages (fully baked). Thus, we may call this as change/migration management project with customized development effort.

Please note that the IDE is IAR EWARM. The problem is the build/compilation console exhibits 0 errors and 0 warnings, subject to elimination of errors and fixing of bugs. Further, on debugging using the OEM's debugger I received the following messages:

"IAR Embedded Workbench X.XX.X (C:\Program Files\IAR Systems\Embedded Workbench X.0\arm\bin\armPROC.dll)

Loaded macro file: C:\Program Files\IAR Systems\Embedded Workbench X.0\arm\config\debugger\OEM\OEM32Z3xx.dmac

Loaded macro file: C:\Program Files\IAR Systems\Embedded Workbench X.0\arm\config\debugger\OEM\OEM32Z3xx_DBG.dmac

Connected to OEM Debugger [SWD mode 1000 kHz] [Access port: 0] Firmware (Probe no: XXXXXXXXXXXXXX)

Hardware reset with strategy 2 was performed

Initial reset was performed

Loaded debugee: C:\Program Files\IAR Systems\Embedded Workbench X.0\arm\config\flashloader\OEM\FlashOEMZ3xxxGNSec.out

Target reset

Downloaded C:\git\Z3_PPPP\Firmware\Projects\Project_Name\Applications\AAA\AAAA_Boot\EWARM\Board_Name\Exe\Project.out to flash memory.

69251 bytes downloaded into FLASH (35.67 Kbytes/sec)

Loaded debugee: C:\git\Z3_PPPP\Firmware\Projects\Board_Name\Applications\AAA\AAAA_Boot\EWARM\Board_Name_In_Part\Exe\Project.out

Hardware reset with strategy 0 was performed

69251 bytes verified (115.80 Kbytes/sec)

Download completed and verification successful.

Hardware reset with strategy 0 was performed

Target reset

Code coverage activated

IAR Embedded Workbench (C:\Program Files\IAR Systems\Embedded Workbench X.0\arm\bin\armPROC.dll)

Loading the OEM Debugger Driver driver"

Based on the debug log, there appear to be no syntactic or semantic errors in the log. The log shows the initialization and connection process of the IAR Embedded Workbench with the OEM debugger and the successful download and verification of the firmware to the microcontroller. Overall, the log indicates a successful initialization and download process without any apparent errors.

The free space is merely 12% of the total space available for the peripheral board. Ideally, for the system to function efficiently free space should be at least 20%. The only available options for optimization in the context of IAR Embedded Workbench – Arm are under three modes:

1. Balanced – Space (or Size) vs Time (or Speed);

2. Size

3. Speed

We have tired all. Apparently, there is excessive memory consumption, subject to implementation of static analysis. I am unable to reach main on debugging.

2 REPLIES 2
lbs
Associate

Checked/Analyzed
      Conducted static analysis

      Implemented all potential optimization options for IAR EWARM IDE
      Compiler Flags
      Linker Configuration

Pavel A.
Evangelist III

I am unable to reach main on debugging.

What does this mean? The IAR X.XX debugger breaks or hangs before reaching main()?

What is the earliest point where you can start debugging (bootloader? the assembly startup code? Reset handler?)

Is this the first time debug attempt on the new board?

Should anything be changed in the debugger "macro" scripts for the new board?

 

The free space is merely 12% of the total space available for the peripheral board. Ideally, for the system to function efficiently free space should be at least 20%. 

RAM or flash? If flash, this is OK, no problem at all. If you are out or RAM and stack overflow occurs - too bad. But even this is not why you cannot get the debugger starting. So I'd suspect first a software misconfiguration (in the mentioned debugger scripts), next a hardware issue such as clocks and power.

Make sure the correct STM32 model is specified in the debug settings! The IAR debugger is picky about this, it may refuse to connect if the actual STM32 model is not as specified.