while(1); loops in system startup and configuration code for most platforms

[mfiore02]

I have spent weeks debugging an issue in a complicated application and finally discovered the problem was a while(1); loop in SetSysClock() a system configuration function. This was extremely frustrating to discover.

In my case, when my device came out of a low power mode running on the HSI clock, I called SetSysClock() to switch back to the HSE clock. For reasons I don't yet know, this function would very very sporadically and infrequently fail to configure either the HSE clock or HSI clock and drop into a while(1); loop. This happened a few times out of hundreds of thousands of cycles, making it nearly impossible (and extremely time consuming) to debug using normal methods.

I did some investigation and found that there are over 100 while(1); loops in the cmsis layer of the mbed library.

grep -r "while *( *1 *)" libraries/mbed/targets/cmsis/ | wc -l
110

Most of them are in system__.c or startup__.c files which obviously contain low level configuration and startup code. These are places where I would definitely want to be notified somehow if things go sideways.

My issue could be hardware related or completely independent of that block of code, but I still think there are better solutions than just dropping into a while(1); loop and giving absolutely no indication that anything is wrong. People are trying to use mbed devices in production and deployment scenarios and this kind of behavior is not appropriate for those situations.

I suggest triggering a soft reset or at least blinking the status LED in an error pattern to give some indication that something is wrong. This needs to be resolved.

[0xc0170]

A lot of them are in teh core cmsis header files, SystemReset() which is fine.

We got two for LPC15xx and LPC11xx, then the rest is in the ST system files, which look like this:

      /* 3- If fail start with HSI clock */
      if (SetSysClock_PLL_HSI() == 0)
      {
        while(1)
        {
          // [TODO] Put something here to tell the user that a problem occured...
        }
      }

Those [TODO] could be using runtime error() function?

cc @bcostm @adustm @sg-

[bcostm]

I agree that it would be better to notify the user with a LED blink when we enter in a while(1) loop.

But for this specific case mentioned above, if we enter here that means that there is NO clock running on the device. So nothing can be do, no code can be executed and I'm afraid the runtime error() will not run. But we can change the [TODO] comment to explain that there is nothing to do here.

[ciarmcom]

ARM Internal Ref: IOTMORF-212

[adustm]

Hello, Can this issue be closed or are you waiting for action on it ?

[mfiore02]

Closing