Dear Sir,
S32K3 SM chapter "5.7 eDMA" provides some safety mechanisms on DMA.
My questions are:
1) The method "5.7.2.1 CRC protecting the eDMA path" requires that the source data remains in the source address area without being consumed by the DMA reading.
If customer uses DMA to transfer data from BCTU FIFO (for ADC results) or LPSPI RxFIFO to SRAM, the source data is taken out from the peripheral registers, thus the source data cannot be transferred to both destination address and CRC module.
Are there any suggestions to implement DMA safety mechanism for this case?
2) The TVF uses only the first 64bits of the DMA FIFO.
If we managed to meet this requirement above (DMA transmission size no bigger than 64bit), does this mean that we don't need to implement the method in "5.7.2.1 CRC protecting the eDMA path"?
3) The Marker Scheme described in " 5.7.2.3 Application software checks protecting the eDMA" looks like it's only suitable for moving data from RAM to RAM.
If we need transfer data between peripherals and SRAM, it's not possible to set a marker in peripheral register area. Are there any suggested safety scheme for data moving between peripheral and SRAM?
In most cases, customer uses DMA to transfer data between peripheral and SRAM.
Regards,
Jason Yang
Solved! Go to Solution.
1) The method "5.7.2.1 CRC protecting the eDMA path" requires that the source data remains in the source address area without being consumed by the DMA reading.
If customer uses DMA to transfer data from BCTU FIFO (for ADC results) or LPSPI RxFIFO to SRAM, the source data is taken out from the peripheral registers, thus the source data cannot be transferred to both destination address and CRC module.
Are there any suggestions to implement DMA safety mechanism for this case?
[EK] - For transferring data from BCTU FIFO or LPSPI RxFIFO, the customer need to have system level plausibility checks/end-to-end checks by application which will include eDMA data path for safety related data transfer from the peripherals
2) The TVF uses only the first 64bits of the DMA FIFO.
If we managed to meet this requirement above (DMA transmission size no bigger than 64bit), does this mean that we don't need to implement the method in "5.7.2.1 CRC protecting the eDMA path"?
[EK] - If the above safety requirement under 5.7.2.2 TVFs protecting the eDMA data path" are fulfilled, then you don't need to implement the method in "5.7.2.1 CRC protecting the eDMA path". Note that this is true for all S32K3xx devices except S32K314, S32K324 and S32K344.
3) The Marker Scheme described in " 5.7.2.3 Application software checks protecting the eDMA" looks like it's only suitable for moving data from RAM to RAM.
If we need transfer data between peripherals and SRAM, it's not possible to set a marker in peripheral register area. Are there any suggested safety scheme for data moving between peripheral and SRAM?
In most cases, customer uses DMA to transfer data between peripheral and SRAM.
[EK] - As discussed in question 1, the transfer between peripheral and SRAM needs to have system level plausibility checks/end-to-end checks by application software which will include eDMA data path for safety related data transfer from the peripherals
1) The method "5.7.2.1 CRC protecting the eDMA path" requires that the source data remains in the source address area without being consumed by the DMA reading.
If customer uses DMA to transfer data from BCTU FIFO (for ADC results) or LPSPI RxFIFO to SRAM, the source data is taken out from the peripheral registers, thus the source data cannot be transferred to both destination address and CRC module.
Are there any suggestions to implement DMA safety mechanism for this case?
[EK] - For transferring data from BCTU FIFO or LPSPI RxFIFO, the customer need to have system level plausibility checks/end-to-end checks by application which will include eDMA data path for safety related data transfer from the peripherals
2) The TVF uses only the first 64bits of the DMA FIFO.
If we managed to meet this requirement above (DMA transmission size no bigger than 64bit), does this mean that we don't need to implement the method in "5.7.2.1 CRC protecting the eDMA path"?
[EK] - If the above safety requirement under 5.7.2.2 TVFs protecting the eDMA data path" are fulfilled, then you don't need to implement the method in "5.7.2.1 CRC protecting the eDMA path". Note that this is true for all S32K3xx devices except S32K314, S32K324 and S32K344.
3) The Marker Scheme described in " 5.7.2.3 Application software checks protecting the eDMA" looks like it's only suitable for moving data from RAM to RAM.
If we need transfer data between peripherals and SRAM, it's not possible to set a marker in peripheral register area. Are there any suggested safety scheme for data moving between peripheral and SRAM?
In most cases, customer uses DMA to transfer data between peripheral and SRAM.
[EK] - As discussed in question 1, the transfer between peripheral and SRAM needs to have system level plausibility checks/end-to-end checks by application software which will include eDMA data path for safety related data transfer from the peripherals