Reply
Posts: 3
Registered: ‎05-26-2017

setting breakpoints causes Simplicity Studio v4 to enter hard fault

Software: Simplicity Studio v4 + Ubuntu 16.04.2 LTS

MCU: external PCB with EFM32GG940F1024

Debugger HW: EFM32 Giant Gecko Starter Kit board (BRD2200A Rev A03) as debugger connected in OUT-mode.

 

Problem description:

When breakpoints are activated in certain places, a hard fault occurs. Sometimes even the breakpoint instruction (0xBE00) ends up in the high 16-bit part of the faulting PC, causing a hard fault when trying to fetch for example address 0xBE001234. This bug also has a special feature, that when having hit a breakpoint in certain places, pressing "reset the device" from the debug menu, you immediately end up in the hard fault handler with the breakpoint instruction seen as the high 16-bit part of the offending address. The lower part of the address is then the address of the first instruction of the reset handler, so the MCU fails to even execute the first instruction after having read the vector table (from flash).

 

I have recorded my desktop when the first variant of the bug happens here:

 

Is this a known bug that has a workaround? Will getting a real Segger J-Link solve it?

Simplicity Studio v4 + Ubuntu 16.04.2 LTS , EFM32GG940F1024, using "EFM32 Giant Gecko Starter Kit board (BRD2200A Rev A03)" as debugger with my own PCB connected in OUT-mode. When breakpoints are activated in certain places, a hard fault occurs. Sometimes even the breakpoint instruction (0xBE00) ...
Posts: 512
Registered: ‎12-05-2016

Re: setting breakpoints causes Simplicity Studio v4 to enter hard fault

Hi @zilog,

 

I am not aware that this is a known bug.  The EFM32GG940F1024 chip errata lists an issue with prefetch in rev. B & C of the chip that can cause a system failure.  But the chip is now at rev. E.  The workaround for the earlier revisions was not to enable prefetch and prefetch is disabled by default.

 

I will transfer this forum post to the Microcontroller forum as they are better able to support this issue.

 

Thank you,

jpitt

Highlighted
Posts: 435
Registered: ‎07-13-2015

Re: setting breakpoints causes Simplicity Studio v4 to enter hard fault

@zilog

Does this issue happen with only this specific piece of software or does it happen with other stuff on the Giant Gecko? Is this issue specific to the Giant Gecko or do you experience this problem with your software on other EFM32 or other ARM Cortex devices?

 

Looking at your video, it seems to me that you have some sort of RTOS and/or a lot of custom assembly code. That can be the cause of several seemingly unexplainable issues and a lot of headache... and sometimes it's very hard to debug.

 

My suggestion is:

 

  • Examine the fault register values in your fault handler
  • Determine why exactly the fault happens ― read the ARM documentation on fault register values.
  • I also suggest the "Definitive Guide to ARM Cortex-M3 and Cortex-M4 Processors" by Joseph Yiu, which explains the possible reasons why each possible fault can happen. It was a great deal of help for me. (And much better than the free docs by ARM.)

 

Some time ago I tried to implement simple cooperative multitasking. The code seemed to work most of the time, but sometimes it failed... For example, I got a fault where the INVSTATE bit was set. The docs say that it happens when you try to switch from Thumb to ARM state, which I surely didn't do... it made no sense until I figured out that jumping to an unaligned address would cause this. (Since I didn't specify alignment, the compiler sometimes aligned it well, and sometimes not... so it was very hard to reproduce and debug.) Then I had some issues with a corrupt PSR, and whatever... it was a headache.

 

Sorry for the rant. Hope this post is at least of some help to you.

 

Posts: 3
Registered: ‎05-26-2017

Re: setting breakpoints causes Simplicity Studio v4 to enter hard fault


jpitt wrote:

Hi @zilog,

 

I am not aware that this is a known bug.  The EFM32GG940F1024 chip errata lists an issue with prefetch in rev. B & C of the chip that can cause a system failure.  But the chip is now at rev. E.  The workaround for the earlier revisions was not to enable prefetch and prefetch is disabled by default.

 

I will transfer this forum post to the Microcontroller forum as they are better able to support this issue.

 

Thank you,

jpitt


Thanks for the reply,

 

I have tested with a Segger J-Link Ultra+ in simplicity Studio now, and the breakpoint-induced bug doesn't happen. Debugging however works bad in other ways now (lots of errors when trying to see variable contents), which I hope will vanish when I have transferred the project to Eclipse.

Posts: 3
Registered: ‎05-26-2017

Re: setting breakpoints causes Simplicity Studio v4 to enter hard fault


Timur wrote:

@zilog

Does this issue happen with only this specific piece of software or does it happen with other stuff on the Giant Gecko? Is this issue specific to the Giant Gecko or do you experience this problem with your software on other EFM32 or other ARM Cortex devices?

 

Looking at your video, it seems to me that you have some sort of RTOS and/or a lot of custom assembly code. That can be the cause of several seemingly unexplainable issues and a lot of headache... and sometimes it's very hard to debug.

 

My suggestion is:

 

  • Examine the fault register values in your fault handler
  • Determine why exactly the fault happens ― read the ARM documentation on fault register values.
  • I also suggest the "Definitive Guide to ARM Cortex-M3 and Cortex-M4 Processors" by Joseph Yiu, which explains the possible reasons why each possible fault can happen. It was a great deal of help for me. (And much better than the free docs by ARM.)

 

Some time ago I tried to implement simple cooperative multitasking. The code seemed to work most of the time, but sometimes it failed... For example, I got a fault where the INVSTATE bit was set. The docs say that it happens when you try to switch from Thumb to ARM state, which I surely didn't do... it made no sense until I figured out that jumping to an unaligned address would cause this. (Since I didn't specify alignment, the compiler sometimes aligned it well, and sometimes not... so it was very hard to reproduce and debug.) Then I had some issues with a corrupt PSR, and whatever... it was a headache.

 

Sorry for the rant. Hope this post is at least of some help to you.

 


My system is based on FreeRTOS 9.0, and runs C++14 using gcc/g++. The only assembly code apart from the startup vector code is fault and error handlers, they don't cause this since they are only invoked after things have gone bad. I inspect the registers you mention in the handlers.