fix(PeriphDrivers): Resolve incorrect DMA request in DMA-based SPI transactions for all parts

[JeonChangmin]

Description

This pull request addresses an issue in the DMA-based SPI transaction implementation where the DMA request would not be executed under specific conditions.

Problem Details

• Issue: When MXC_SPI_MasterTransactionDMA is called with txData == NULL and rxData != NULL in SPI_WIDTH_STANDARD (full duplex) mode, the function sets reqselTx to -1. However, in MXC_SPI_RevA1_MasterTransactionDMA, MXC_SPI_RevA1_TransSetup may additionally set txData based on the request. This leads to the use of an invalid request selector, causing the DMA to not be executed and resulting in an infinite wait state.

• Call Stack:

  • MXC_SPI_MasterTransactionDMA
    • Determines reqselTx and reqselRx based on the device and data presence.
  • MXC_SPI_RevA1_MasterTransactionDMA
    • Uses MXC_SPI_RevA1_TransSetup to configure the request, potentially modifying req to include both Tx and Rx data.
  • MXC_SPI_RevA1_TransSetup
    • Adjusts the request to comply with SPI protocol, potentially setting both Tx and Rx data.

Solution

• Always pass valid reqselRx and reqselTx values from MXC_SPI_MasterTransactionDMA.
• Configure DMA in MXC_SPI_RevA1_MasterTransactionDMA after executing MXC_SPI_RevA1_TransSetup.

Solution Rationale: By ensuring valid reqselRx and reqselTx values are always passed from MXC_SPI_MasterTransactionDMA, the MXC_SPI_RevA1_MasterTransactionDMA function can correctly configure the DMA settings based on the request. This prevents the DMA from not being executed due to invalid request selectors. Additionally, the MXC_SPI_RevA1_MasterTransactionDMA function always checks the null status of rxData and txData before using the request selectors, ensuring that no other issues arise from this change.

Additional Fixes

• Applied the same fix to MXC_SPI_SlaveTransactionDMA.
• Corrected potentially swapped reqselRx and reqselTx values in spi_me11.c and spi_me18.c files. Please confirm if this change was intended. (fix in this PR)

Tests

• Tested the changes on a MAX78000 device using spi_me17.c as a basis.

Checklist Before Requesting Review

• PR Title follows correct guidelines.
• Description of changes and all other relevant information.
• Provide info on any relevant functional testing/validation.

[Jake-Carter]

Thank you for your very nice PR.

Can confirm you've caught some copy/paste typos on the mismatched reqsel values.

The AI87 values are also swapped if you wouldn't mind fixing that as well.

[Jake-Carter]

AI87 implementation has SPI0/SPI1 swapped as well. Should be reqselTx = MXC_DMA_REQUEST_SPI0TX; here.

Not your fault, this was there before your fix.

[sihyung-maxim]

I believe the original implementation was correct. SPI0 and SPI1 are swapped in several places as an unfortunate result of incorrect documentation, and it's been stuck like that ever since to prevent breaking projects... It's why we have messes like this for the ME17, AI85, and AI87.

I say we fix this even if it might break existing projects. Usually, instance 0 is mapped to the lowest peripheral address, and then everything goes in ascending order:

1. SPI0 (APB) - 0x40046000
2. SPI1 (APB) - 0x40047000
3. SPI[n] (APB) - 0x4004m000
4. SPI[n+1] (AHB) - 0x400BE000
5. SPI[n+2] (AHB) - 0x400BE400

However, the ME17, AI85, and AI87 doesn't follow this:

1. SPI0 (AHB) - 0x400BE000
2. SPI1 (APB) - 0x40046000

This has caused confusion, but it'll be a major breaking change to swap the SPI instance names. Instead, we can fix the MXC_SPI_GET_* definitions in the {device}.h file where SPI0 would be associated with index 0, and SPI1 with index 1. This would still be a breaking change, but it would at least help keep all the indexing aligned with the correct SPI names.

What do you think? @Jake-Carter & @lorne-maxim

[JeonChangmin]

Thanks for the review!
I fixed the cases where spi_num and reqselTx/Rx didn't match as you suggested.
There are more than AI87, so I fixed all of them, but please let me know if there is something else you intended.

[Jake-Carter]

Thanks @JeonChangmin, no this is good. Looks like the same mistake got copy/pasted across the drivers since the ME12.