topic K22 bug in MK22F12.h for SPI configurations in Kinetis Software Development Kit

K22 bug in MK22F12.h for SPI configurations

joelwigton — Fri, 28 Oct 2016 15:19:13 GMT

When you use the project generator to make a MK22F12 project, I get the following compiler warnings (though serious):

array subscript is above array bounds [-Warray-bounds]

Which is pointing to fsl_dspi.c:

#if defined(SPI0)
void SPI0_DriverIRQHandler(void)
{
 assert(g_dspiHandle[0]);
 DSPI_CommonIRQHandler(SPI0, g_dspiHandle[0]);
}
#endif
#if defined(SPI1)
void SPI1_DriverIRQHandler(void)
{
 assert(g_dspiHandle[1]);
 DSPI_CommonIRQHandler(SPI1, g_dspiHandle[1]);
}
#endif
#if defined(SPI2)
void SPI2_DriverIRQHandler(void)
{
 assert(g_dspiHandle[2]);
 DSPI_CommonIRQHandler(SPI2, g_dspiHandle[2]);
}
#endif

Lines 12 and 19 are the issue, because these are referencing elements 1 and 2 of the g_dspiHandle[] array, but it is only defined in that same file as static void *g_dspiHandle[FSL_FEATURE_SOC_DSPI_COUNT]; and FSL_FEATURE_SOC_DSPI_COUNT is defined elsewhere in the MK22F12_features.h file as 1!

In other words, there is only one SPI block (SPI0) on this chip, so the SPI1 and SPI2 features should not be defined, and this error will go away. I have confirmed that eliminating these variables (SPI1, SPI2, etc.) in MK22F12.h fixes the issue.

Please fix in future versions, thanks.

Joel

Re: K22 bug in MK22F12.h for SPI configurations

ivadorazinova — Mon, 31 Oct 2016 18:09:58 GMT

Hi Joel.

Thank you for your feedback.

MKxx_features.h is a file, which contains SoC module features and dspi driver is the same for most of Kinetis MCUs.

So in this case we don´t avoid this warning.

Best Regards,

Iva

Re: K22 bug in MK22F12.h for SPI configurations

guylejeune — Wed, 15 Feb 2017 10:49:43 GMT

Hi,

this bug has another side effect.

In my case, I wanted to use SPI2.

Configuring the SPI2 interface leads to a HardFault, caused itself by a memory access to the main configuration register (SPI2->MCR).

The chip reacts so because SPI2 is not clocked, even though this is the first action performed by DSPI_MasterInit

To be clocked, the driver tries to recognise the SPI instance first:

uint32_t DSPI_GetInstance(SPI_Type *base)
{
    uint32_t instance;
   /* Find the instance index from base address mappings. */
    for (instance = 0; instance < FSL_FEATURE_SOC_DSPI_COUNT; instance++)
    {
        if (s_dspiBases[instance] == base)
        {
            break;
        }
    }
   assert(instance < FSL_FEATURE_SOC_DSPI_COUNT);
   return instance;
}‍‍‍‍‍‍‍‍‍‍‍‍‍‍

As pointed by Joel, FSL_FEATURE_SOC_DSPI_COUNT is set to 1. So this function exits the loop before trying to recognize the SPI instance.

In my case, it gets even worse: I use the NDEBUG parameters, so the assert functions is not doing anything. So even if the function failed to recognized a valid SPI instance, it returns the value 0, which is a valid SPI instance.

This then leads to enable the wrong SPI clock. Which will crash the chip when the code tries to go further with the initialization.

Since there is 3 SPI intstance on the chip I suggest to correct FSL_FEATURE_SOC_DSPI_COUNT to value 3.