AnsweredAssumed Answered

Reporting of issues in S32K SDK

Question asked by Maksim Salau on Apr 25, 2018
Latest reply on May 4, 2018 by Maksim Salau



I'm playing with S32K144 and its SDK. Thanks for the SDK, it makes bring-up much easier!


I have found some places that can be improved. I want to report them so the development team can improve the SDK.

What is the preferred way to report such issues?


Here are issues I've found so far:

1. Incorrect type used for the timeout argument: SPI_MasterTransferBlocking accepts `uint16_t timeout` and passes the value to LPSPI_DRV_MasterTransferBlocking which accepts `uint32_t timeout`

status_t SPI_MasterTransferBlocking(
    spi_instance_t instance,
    void* txBuffer,
    void* rxBuffer,
    uint16_t numberOfFrames,
    uint16_t timeout);
status_t LPSPI_DRV_MasterTransferBlocking(
    uint32_t instance,
    const uint8_t * sendBuffer,
    uint8_t * receiveBuffer,
    uint16_t transferByteCount,
    uint32_t timeout);

Thus if you try to pass OSIF_WAIT_FOREVER, the compiler shows a warning that truncation will occur.


2. Incorrect C guards in can_pal.h:

#if defined(__cplusplus)
extern "C" {

#if defined(__cplusplus)

Literally. I.e. `extern "C" {}` doesn't protect function prototypes.


3. The LPUART driver allows to set custom RX and TX handlers/callbacks so one can implement his own logic, but `lpuart_hw_access.h` is not in the `drivers/inc` directory, and thus is not generally accessible. So we end up in a situation that you can define a custom handler but can't transmit a byte with `LPUART_Putchar()`, since the SDK has no header for it in `drivers/inc`. So I propose to either move `lpuart_hw_access.h` to `drivers/inc` or create a wrapper in `lpuart_driver.c|h`

The following function can act as the wrapper:

static void LPUART_DRV_PutData(uint32_t instance)

but it is defined as static. Making it public will solve my pain


4. Processor Expert shows incorrect frequency for divided clocks:

I.e PE shows 8MHz for both SIRCDIV1_CLK and SIRCDIV2_CLK. Same issue for all other clocks in the list.


5. PE doesn't generate a macro that defines SPI_PAL instance number.

I.e. for UART_PAL the following macro is defined in uart_pal1.h:

/*! @brief Device instance number */
#define INST_UART_PAL1 (1U)

But spi_pal1.h doesn't have such macro.


I hope this information will allow to make the SDK and PE even better.


Best regards,