EnterCritical() causes hard fault on KE04

[jay_d_carlson]

I've created an AsynchroSerial component in a Processor Expert 1.x project targetting a KE04 microcontroller. Unfortunately, during initialization, when the ReceiveBlock() function calls EnterCritical(), the core jumps to the hard fault handler, specifically on the strb instruction:

What's going on here?

[BlackNight]

Hi Jay,

could you show the content of the registers (Register view)? It could be that your stack pointer is bogus somehow.

Other than that, you could use that hard fault helper I wrote (see Debugging Hard Faults on ARM Cortex-M | MCU on Eclipse  for a plain code variant and A Processor Expert Component to Help with Hard Faults | MCU on Eclipse  for a Processor Expert component.

Because HardFaults can be delayed, a useful thing is to disable the write buffer. The above component has a setting for this:

Have a look at Debugging ARM Cortex-M0+ HardFaults | MCU on Eclipse  for this and other tips.

I hope this helps,

Erich

[jay_d_carlson]

Thanks — I actually remembered you blogging about that after I posted the message, and tracked down that code :-)

I'm thinking there might be an issue with my J-Link setup. When I started this project a few nights ago, I was using the "GDB SEGGER J-Link Debugging" type of debug configuration. But whenever I try to start a debugging session, I I get an error:

Error in final launch sequence
Failed to execute MI command:
-exec-run

Updated to the latest version of Segger, updated the KDS DLL for it, as well as the firmware. No dice.

Since I just wanted to get something working, I switched over to manually invoking the J-Link GDB server, and connecting to it in Kinetis Design Studio using the "GDB Hardware Debugging" option. Seemed to work on some basic tests, so I started on the project (which is a DMX-512 receiver with an RGB LED).

After posting that message and trying to track down the PC of the hard fault, they vanished. I realized that when I killed the GDB server and power-cycled the MCU, the hard faults went away. Not sure if some flash memory wasn't getting programmed and the debugger was wandering off somewhere, but that problem is gone.

An even bigger problem: when my debugger is attached to my MCU, UART interrupts aren't firing. And I have no idea why. The moment I disconnect the debugger and power-cycle my MCU, it starts doing what it's supposed to be doing.

...well, unless I dial in a receive buffer larger than about 450 bytes in the PE AsynchroSerial component. Then it stops working altogether: a single OnRxChar() callback gets invoked, at the start, but then it stops invoking, I never get the OnFullRxBuff() callback, and the OnBreak() callback doesn't fire either. 

I can't really investigate either of these problems, since the "Peripherals" tab in Kinetis Design Studio is blank (I assume this is a "GDB Hardware Debugging" limitation?). So I think I need to go back and figure out why I can't use the normal Segger debug configuration. This is a fresh install of KDS 3.2.0, so I'm not sure what software incompatibility issues there might be. Note that I have a lot of IDEs on my computer right now. I suppose something could be conflicting, but I don't know how to even begin to track something like that down?

This whole setup feels a lot clunkier than last time I used Kinetis Design Studio a few years ago. I'm just trying to build a simple RGB LED DMX-512 receiver, as part of a review of different microcontrollers for my blog. This was my entry into the ARM ecosystem several years ago, and I have a lot of fond memories building projects in Processor Expert (back in the Code Warrior days!), so I was excited to reacquaint myself with the platform. Unfortunately, things are not going well at all so far.

[BlackNight]

Hi Jay,

the 'Peripherals' view works with CMSIS-PACK files (see Are ARM CMSIS-Pack the Future of Software Components? | MCU on Eclipse ), so you would have to install these first. I don't recommend using CMSIS-PACK files unless you are familiar with the packs and their approach.

Instead, the normal way to see in KDS the peripherals registers is using the EmbSysReg view. That plugin is already installed in KDS (see How to Add Register Details View in Eclipse | MCU on Eclipse  which includes installation of it, but have a read how to use it: you have to assign the microcontroller with the 'wrench' icon and double click on a register/group to activate it).

As for the hardfault (or other problem): keep in mind that the debug cable is making an electrical connection to your board. I have seen in the past issues with ground loops and other kind of things because of the debug cable connection. Or that noise was injected to the board through the cables. Keep an eye on the reset circuit (pull-up resistor and capacitor too).

I hope this helps,

Erich

[jay_d_carlson]

Erich, thanks! This gave me some helpful insight. I think I might have to spend a few weeks reading through your entire blog. So much good content to read. Thanks for all your contributions to the community!