I just stumbled upon a possible bug in the SPI driver of the LPCXpresso54608 SDK (SDK version 2.5.0)
If the SPI_MasterHalfDuplexTransferBlocking function is used to only write data, the SPI signals are in a wrong state after this function finishes.
E.g: if the clock polarity is "active high" (low in stand by), the clock will be low before the transfer but it will stay high at the end of the transfer.
Looking at the source code, I see that the HalfDuplexTransfer functions calls the SPI_MasterTransferBlocking twice; first with the tx (or rx) data and a second time for the rx (or tx) data. But no check is done to see if the dataSize is 0.
This results in an invalid situation where MasterTransferBlocking() is being requested to send (or receive) 0 bytes.
My easy fix is to use the SPI_MasterTransferBlocking() but then I need to have an extra variable for the xfer parameter.
I implemented a final fix by adding an extra check in the HalfDuplexTransfer to check on both instances for a valid dataSize.
The SPI_MasterTransferBlocking() function has a parameter check at the start of a function but there is no check on the dataSize. Adding this check will make sure that the driver does not leave the SPI pins in an incorrect state.